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5 PRESENCE SERVER IN IP MULTIMEDIA 

Field of the Invention 

The present invention relate S to the provision of a system 
architecture in an packet switched environment, and 
particularly to the implementation in such an architecture of 
L0 means for providing information about a user's presence. 
Background to the Invention 

in third generation (3G) mobile networks services are provided 
over IP networks, which results in the integration of voice 
and data applications. One of the major candidates for the 

15 emerging new IP based services is to provide information about 
the user's presence. Presence is defined as subscription to 
and notification of changes in the communications state of a 
user. This communications state consists of the set of: 
communications means; communications address; and status of 

20 that user. 

In third generation networks, call control and the service 
creation environment are based on a session initiation 
protocol (SIP) , as described in 3* Generation Partnership 
Project, Technical Specification Group Services and System 
25 Aspects, IP Multi-Media Sub-System - Stage 2, 3G TS 23.228 
version 1.7.0, February 2001. 

internet Engineering Task Force, Internet Draft, draft- 
rosenberg-impp-presence-ol.txt, Rosenberg et al, published 2 nd 
March 2001, the contents of which are incorporated herein by 

30 reference as Annex A, proposes an extension to SIP for 
subscriptions and notifications of user presence. User 
presence is defined as the willingness and ability of a user 
to communicate with other users on the network. Historically, 
presence has been limited to "on-line" and -off-line" 

35 indicators. The notion of presence in Rosenberg et al is 
broader. Subscriptions and notifications of user presence are 
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5 supported by defining an event package within the general SIP 
event notification framework. This protocol is also compliant 
with the common presence and instant messaging (CPIM) 
framework. However, such proposal does not include any 
consideration of multimedia environments. 

10 The SIP extension defined in Rosenberg et al is based on the 
concept of a presence agent (PA) , which is a new logical 
entity that is capable of accepting subscriptions (through a 
SUBSCRIBE message) , storing a subscription state, and 
generating notifications (through a NOTIFY message) when there 

15 are changes in user presence. 

The aim of this invention is to provide a technique for the 
session initiation protocol registration, subscription and 
notification procedures in an internet protocol multimedia 
subsystem. 

20 Summary of the Invention 

The aim of the present invention is achieved by providing a 
presence server in the architecture. The presence server is 
preferably provided as part of the application and services 
1 cloud' or environment. By providing the presence server in 
25 the architecture, subscribers are able to receive information 
about other subscriber's presence. 

The present invention is related to 3GPP (3 rd Generation 
Partnership Project) Release 5/6 standardization. 

In accordance with the present invention there is provided a 
30 packet switched environment, including the functionality of a 
presence server in an application and services environment. 

The packet switched environment is preferably an internet 
protocol multimedia environment, and preferably a subsystem of 
an all-IP telecommunications network. 
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5 In a first embodiment the interrogating call state control 
function (I-CSCF) updates the presence information in the 
presence server by forking an incoming REGISTER message. 

In a second embodiment the serving call state control function 
(S-CSCF) acts as a presence agent and the presence server 
10 provides the task of storing information about the 
subscribers . 

In a third embodiment the presence server in the internet 
protocol multimedia (IM) sub-system behaves as a presence 
agent and the serving call state control function (S-CSCF) 
15 uses a separate REGISTER transaction to update the presence 
information in the presence server. 

The invention thus solves the problem of routing of the 
REGISTER, SUBSCRIBE and NOTIFY messages in an internet 
protocol multimedia (IM) subsystem. 

20 Brief Description of the Drawings 

The invention will now be described by way of reference to the 
accompanying drawings, in which: 

Figure 1 represents the 3GPP Release 5 architecture embodying 
the present invention; 

25 Figure 2 represents the flow of REGISTER messages in a first 
embodiment of the present invention; 

Figure 3 represents the flow of SUBSCRIBE messages in a first 
embodiment of the present inventions- 
Figure 4 represents the flow of NOTIFY messages in a first 
30 embodiment of the present invention; 

Figure 5 represents the flow of SUBSCRIBE messages in a second 
embodiment of the present invention; 

Figure 6 represents the flow of NOTIFY messages in a second 
embodiment of the present invention; 
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5 Figure 7 represents the flow of REGISTER usages in a third 
embodiment of the present invention; 

Figure 8 represents the flow of SUBSCRIBE messages in a third 
embodiment of the present invention; and 

Figure 9 represents the flow of NOTIFY messages in a third 
10 embodiment of the present invention. 
n ao .ripti Q n of P ref ~-™d Embodiments 

The present invention places a presence server in the internet 
rnultimedia subsystem of the 3GPP Release 5 architecture as 
part of the Application and services cloud' . The internet 

15 protocol multimedia subsystem refers to the set of Core 
Network entities using the services provided by the packet 
switched domain of the 3GPP Release 5 architecture to offer 
.ultimedia services. The entities of the internet protocol 
.nultimedia subsystem are the CSCF, the MGCF, the MRF and some 

20 adaptation entities. The representation of the extended 
architecture is shown in Figure 1 . 

Figure 1 is based on a basic 3 GPP architecture in accordance 
with the architecture defined in 3* Generation Partnership 
Project; Technical Specification Group Services and Systems 

25 Aspects; Architecture for an All-IP Network; 3G TR 23.922 
version 1.0.0; October 1999, the contents of which are herein 
incorporated by reference as Annex B. However, the 
architecture disclosed therein is modified, as shown in Fxgure 
lf to include a presence server in accordance with the present 

30 invention. 

The present invention is particularly concerned with the flow 
of REGISTER, SUBSCRIBE and NOTIFY messages in a 3GPP network. 
The present invention will now be described in further detail 
with reference to three exemplary embodiments of REGISTER, 
35 SUBSCRIBE, and NOTIFY message flows. It should be noted that 
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only the necessary parts of the network - and message flows - 
needed for operation of the present invention are described in 
the following examples. 

One general requirement for all the described embodiments is 
that the user's profile information must contain the name of 
the presence server associated with that user. 
The routing of the REGISTER/ SUBSCRIBE /NOTIFY messages of a 
first embodiment is described hereinbelow with reference to 
Figures 2 to 4. 

In this first embodiment, the interrogating call state control 
function (I-CSCF) updates the presence information in the 
presence server by forking an incoming REGISTER message. 
A first network corresponds to the visited network of the 
presence user agent (FUA) , and includes user equipment <UE) 
200, and a proxy call state control function (P-CSCF) 202. The 
first network is also the presence agent's network. 
A second network corresponds to the home network of the 
presence user agent (PUA) , and includes an interrogating -call 
state control function (I-CSCF) 204, a (HSS) 206, a serving 
call state control function (S-CSCF) 208, and a presence 
server (PS) 210. 

A third network corresponds to the home network of the 
subscriber, and includes a UE subscriber 212, a first proxy 
call state control function (P-CSCF#1) 214, a first serving 
call state control function <S-CSCF#1) 216, an interrogating 
call state control function (I-CSCF) 218, a (HSS) 220, a 
second serving call-state control function (S-CSCF#2) 222, and 
a second proxy call state control function (P-CSCF#2) 224. 
Referring to Figure 2, there is illustrated an extended 
registration message flow in accordance with this first 
embodiment of the present invention. 
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5 As represented by step 230, the routing of the REGISTER 
message, initiated by the user equipment 200, takes place 
between the UE 200, the first network P-CSCF 202 and the 
second network I-CSCF 204. The name of the presence server 210 
is part of the subscriber's profile, and this is retrieved by 
10 the I-CSCF 204 from the HSS 206 in a step 232. In a step 234 
the I-CSCF 204 selects a S-CSCF for the session initiation, 
which in this example is the S-CSCF 208. 

As represented by messages 236 and 238, the I-CSCF 204 forks 
the incoming REGISTER message such that, in accordance with 
15 this embodiment, it is forwarded to both the S-CSCF 208 and 
the PS 210. Thereafter w 200 OK" messages are transmitted back 
to the UE 200 along the reverse route. 

Referring to Figure 3, there is illustrated a routing of the 
SUBSCRIBE message flow in accordance with this first 
20 embodiment of the present invention. 

As represented by messages 240, 242, and 244, the SUBSCRIBE 
message is routed to the I-CSCF 204 from the UE subscriber 212 
via the P-CSCF#1 214 and S-CSCF#1 216. 

As represented by message 246, the I-CSCF 204 routes the 
25 received SUBSCRIBE message directly to the PS 210. Thereafter 
*202 Accepted" messages are routed back to the UE subscriber 
along the reverse route. 

Referring to Figure 4, there is illustrated a routing of the 
NOTIFY message flow from the presence server 210 in accordance 
30 with this first embodiment of the present invention. 

The PS 210, as represented by the message 248, forwards the 
NOTIFY message to the I-CSCF 218. Following a local query to 
the HSS 220 in step 249 the I-CSCF, as represented by messages 
250, 252 and 254, forwards the NOTIFY message to the UE 
35 subscriber 226 via the S-CSCF#2 222 and the P-CSCF#2 224. Thus 
the PS 210 sends the NOTIFY message directly to -the other 
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networks I-CSCF 218. Once again, "200 OK" messages are routed 
back to the PS 210 along the reverse route. 

in summary, the first embodiment sets the following new 
requirements to the network elements placed in the 
architecture: 

1. I-CSCF downloads (part of) the subscriber's profile from 
HSS in order to find the subscriber's presence server; 

2. I-CSCF forks the incoming REGISTER of PUA to the S-CSCF and 
to the presence server ,- 

3. I-CSCF routes the incoming SUBSCRIBE requests to the 
presence server directly; and 

4. The presence server sends the outgoing NOTIFYs directly to 
other network's I-CSCF. 

The routing of the SUBSCRIBE/NOTIFY messages in accordance 
with a second embodiment of the invention is described 
hereinbelow with reference to Figures 5 and 6. 
Since the S-CSCF stores the subscriber profile and the contact 
information provided in the REGISTER message, a trivial 
solution is for the S-CSCF to act as a presence agent. One 
possible problem with this solution is that the S-CSCF would 
have to store information about all the subscribers and 
generate NOTIFY messages to all of them. 

Therefore, in the second described embodiment, the task of 
storing information about each subscribers is provided by the 
newly introduced presence server. For the S-CSCF it is enough 
to receive only the first SUBSCRIBE message for the 
presentity, since it will generate the NOTIFY message for the 
one subscription, and this NOTIFY message will be forked to 
the subscribers by the proxy server, which has the information 
about the subscribers. 
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5 The registration flow in this solution corresponds to the 
normal registration as defined by 3G TS 23.228 version 1.7.0, 
February 2001, discussed hereinabove in the introduction. 

The routing of the SUBSCRIBE/NOTIFY messages in accordance 
with the second embodiment of the present invention is 
10 described hereinbelow with reference to Figures 5 and 6. 
Elements of the first, second and third networks corresponding 
to elements shown in Figures 2 to 4 are referenced in Figures 
5 and 6 using the same reference numerals. 

In addition to the elements shown in Figures 2 to 4, for the 
15 purposes of describing the second embodiment the third 
network, corresponding to the home network of the subscriber, 
includes two user equipment subscribers UE subs#l 302 and UE 
subs#2 304. Furthermore, the second network, corresponding to 
the home network of the PUA, includes a second serving call 
20 state control function S-CSCF#2 306. 

Referring to Figure 5, there is illustrated a routing of the 
SUBSCRIBE message flow in accordance with this embodiment of 
the present invention. 

A SUBSCRIBE message from the first user equipment subscriber 
25 302 is forwarded to the P-CSCF#1 214, as illustrated by 
message 308a. Such message is forwarded, in turn, to the S- 
CSCF#1 216 and the I-CSCF 204 as illustrated by messages 310a 
and 312a. Following a local query in step 313a, the SUBSCRIBE 
message is forwarded to the PS 210, as represented by message 
30 314a. Subsequent thereto, the SUBSCRIBE message is forwarded 
from the PS 210 to the S-CSCF#2 306, as represented by message 
316. 

Responsive to the SUBSCRIBE message 316 from the presence 
server 210 corresponding to the first user equipment 
35 subscriber 302 of the third network, the S-CSCF#2 returns an 
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5 acknowledgement message by way of an accept signal, as 
represented by arrow 318. 

Similarly a SUBSCRIBE message from the second user equipment 
subscriber 304 is forwarded to the P-CSCF#1 214, as 
illustrated by message 308b. Such message is forwarded, in 
10 turn, to the S-CSCF#1 216 and the I-CSCF 204 as illustrated by 
messages 310b and 312b. Following a local query in step 313b, 
the SUBSCRIBE message is forwarded to the PS 210, as 
represented by message 314b. 

It is not necessary for the presence server 210 -to forward any 
15 subsequent SUBSCRIBE messages from user equipment of the third 
network, as the S-CSCF#2 306 has already provided a successful 
acknowl edgement . 

Acceptance signals for each user subscriber are returned to 
the respective subscribers along reverse paths, responsive to 
20 receipt of the message 318 and an appropriate SUBSCRIBE 
message 314. 

Referring to Figure 6, there is illustrated a routing of the 
NOTIFY message flow from the presence server 210 in accordance 
with this embodiment of the present invention. 

25 As represented by message 320, a single NOTIFY message is 
forwarded from the S-CSCF#1 to the presence server 210. 

The presence server, as represented by message 322a then 
forwards a first NOTIFY message to the I-CSCF 218. Following a 
first local query 324a, the first NOTFIY message is forwarded 
30 to the first user equipment subscriber 302 via, in turn, the 
S-CSCF#2 222 and the P-CSCF#2 224, as represented by messages 
326a, 328a, and 330a. 

The presence server, as represented by message 322b also 
forwards a second NOTIFY message to the I-CSCF 218. Following 
35 a second local query 324b, the second NOTFIY message is 
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5 forwarded to the first user equipment subscriber 302 via, in 
turn, the S-CSCF#2 222 and the P-CSCF#2 224, as represented by 
messages 326b, 326b, and 330b. 

"200 OK" messages are returned to the presence server 210 via 
a reverse path, and a single "OK" message forwarded to the S- 
10 CSCF#1. 

The routing of the REGISTER/ SUBSCRIBE/NOTIFY messages in 
accordance with a third embodiment of the present invention is 
described hereinbelow with reference to Figures 7 to 9. 

The solution described in this third embodiment can be 
15 summarised as : the presence server in the internet protocol 
multimedia subsystem behaves as a presence agent, and the S- 
CSCF uses a separate REGISTER transaction to update the 
presence information in the presence server. 

The routing of the REGISTER/SUBSCRIBE/NOTIFY methods is 
20 described hereinafter with reference to Figures 7 to 9. 
Elements of the first, second and third networks -corresponding 
to elements shown in Figures 2 to 6 are referenced in Figures 
7 to 9 using the same reference numerals. 

Referring to Figure 7, there is illustrated an extended 
25 registration message flow in accordance with this third 
embodiment of the present invention. 

As represented by step 230, the routing of the REGISTER 
message takes place between the UE 200, the first network P- 
CSCF 202 and the second network I-CSCF 204. 

30 Thereafter, in a step 702, the I-CSCF 204 selects a S-CSCF 208 
for the session initiation, which in this example is the S- 
CSCF 208. 

As represented by message 704, the REGISTER message is then 
forwarded to the S-CSCF 208. 
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The name o£ the presence server 210 is part of the 
.briber, s profile, and this is retrieved by the I-CSCF 204 
from the HSS 206 in a step 708. 

Following sucoessful initiation with the S-CSCF 208. a -200 
OK" message is transmitted to the UE 200 along a -reverse prth. . 
Thereafter, as represented by message 710. the REGISTER 
message is forwarded to the presenoe server 210. The message 
710 constitutes a separate REGS1TER transaction with whioh the 
S-CSCF updates the presence information in the PS. 
If the presenoe update fails at the presence server, the S- 
CSCF generates a notification to the UE 200 indicating the 
presence update failure event. For this notification a SIF 
«OTm message can be used, for example, containing an event 
header with a new presence failure reason code. This example 
U illustrated in Figure 7 labelled a. 711. The NOTIFY is then 
acknowledged by the UE 200 to the S-CSCF 208 using a -200 OK- 
message. 

Referring to Figure 8, there is illustrated a routing of the 

~ in accordance with this third 

SUBSCRIBE message flow in accoiraai^ 

embodiment of the present invention. 

A SUBSCRIBE message from the user equipment subscriber 212 is 
forwarded to the P-CSCF#1 214, as illustrated by message 712. 
Such message is forwarded, in turn, to the S-CSCF#l 21, and 
the I-CSCF 204 as illustrated by messages 714 and 716. 
Following a local query in step 718, the SUBSCRIBE message is 
forwarded to the S-CSCF#2 306, as represented by message 720. 
subsequent thereto, the SUBSCRIBE message is forwarded from 
the S-CSCF#2 306 to the PS 210, as represented by message 720. 
Thereafter a »202 Accepted" message is sent along the reverse 
path . 
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5 Referring to Figure 9, there is illustrated a routing of the 
NOTIFY message flow from the presence server 210 in accordance 
with this third embodiment of the present invention. 

As represented by message 722 , a NOTIFY message is forwarded 
from the presence server 210 to the S-CSCF#1 306. The S-CSCF#1 
10 306, as represented by message 724 then forwards the NOTIFY 
message to the I-CSCF 218. Following a local query in step 
726, the NOTIFY message is forwarded to the user equipment 
subscriber 226 via, in turn, the S-CSCF#2 222 and the P-CSCF#2 
224, as represented by messages 728, 730, and 732. 

15 Thereafter a w 200 OK" message is sent along a reverse path. 

The new requirements for the network elements placed in the 
architecture due to the third embodiment cab be summarised as 
below: 

1. The S-CSCF updates the presence information in the PS with 
20 a separate REGISTER transaction. 

2. If the presence update fails at the PS, the S-CSCF 
generates a notification message (e.g. SIP NOTIFY using the 
Evenyt header with a new presence failure reason code) to 
the UE indicating the presence failure update event. 

25 3 . The SUBSCRIBE generated by the subscriber has to be routed 
by the network as it would be a normal INVITE, only the S- 
CSCF of the PUA routes the SUBSCRIBE to the PS associated 
with the presentity. 

4. The NOTIFY generated by the PS has to be routed by the 
30 network as it would be a normal INVITE. 

Although the present invention has been described with 
reference to three exemplary embodiments, the present 
invention more generally presents ways of implementing the 
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5 idea presented in Rosenberg et al with 3GPP proposed 
architecture . 
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This communications state consists of the set of communications 
means, communications address, and status of that user. A presence 
protocol is a protocol for providing such a service over the Internet 
or any IP network. 

This document proposes an extension to the Session Initiation 
Protocol (SIP) [2] for presence. This extension is a concrete 
instantiation of the general event notification framework defined for 
SIP [31. and as such, makes use of the SUBSCRIBE and NOTIFY methods 
defined there. User presence is particularly well suited for SIP. SIP 
reqistrars and location services already hold user presence 
information; it is uploaded to these devices through REGISTER 
messages, and used to route calls to those users. Furthermore, SIP 
networks already route INVITE messages from any user on the network 
to the proxy that holds the registration state for a user. , ^ this 
state is user presence, those SIP networks can also allow SUBSCRIBE 
requests to be routed to the same proxy. This means that SIP networks 
can be reused to establish global connectivity for presence 
subscriptions and notifications. 

This extension is based on the concept of a presence agent, which is 
a new logical entity that is capable of accepting subscriptions, 
storing subscription state, and generating notifications when there 
are changes in user presence. The entity is defined as a logical one, 
since it is generally co-resident with another entity, and -can even 
move around during the lifetime of a subscription. 

This extension is also compliant with the Common Presence and Instant 
Messaging (CPIM) framework that has been defined in [4] . This allows 
SIP for presence to easily interwork with other presence systems 
compliant to CPIM. 

2 Definitions 

This document uses the terms as defined in [1] . Additionally, the 
following terms are defined and/or additionally clarified: 

Presence User Agent (PUA) : A Presence User Agent manipulates 
presence information for a presentity. In SIP terms, this 
means that a PUA generates REGISTER requests, conveying 
some kind of information about the presentity. We 
explicitly allow multiple PUAs per presentity. This means 
that a user can have many devices (such as a cell phone and 
PDA) , each of which is independently generating a component 
of the overall presence information for a presentity. PUAs 
push data into the presence system, but are outside of it, 
in that they do not receive SUBSCRIBE messages, or send 
NOTIFY. 



Rosenberg et al. 



(Page 2) 



WO 02/096128 W < FCT/IB02/02212 

16 



nr^senee March 2, 2001 

internet Draft presence 

Presence Agent (PA) : A presence agent is a SIP user agent which 
S capable of receiving SUBSCRIBE requests, -responding to 
them, and generating notifications of changes in Presence 
state. A presence agent must have complete knowledge of the 
presence state of a presentity. Typically, tins is 
accomplished by co-locating the PA with the 
nroxv/registrar, or the presence user agent of the 
lll7enlll V . A PA is always addressable with a SIP URL. 

Presence Server: A presence server is a logical entity that can 
alt as either I presence agent or as a proxy server for 
SUBSCRIBB requests. When acting as a PA it is aware of the 
presence information of the presentity through some 
protocol means. This protocol means can be SIP REGISTER 
requests, but other mechanisms are allowed. When acting as 
a proxy, the SUBSCRIBB requests are proxied to another 
entity that may act as a PA. 

Presence Client: A presence client is a Presence agent that is 
colocated with a PUA. It is aware of the presence 
information of the presentity because it is co-located with 
the entity that manipulates this presence information. 

3 Overview of Operation 

in this section, we present an overview of the operation of this 
extension. 

When an entity, the subscriber, wishes to learn about presence 
^formation from some user, it creates a SUBSCRIBE request . This 
request identifies the desired presentity in the request URI. «*ing 
either a presence URL or a. SIP URL. The subscription is carried along 
SIP proxies as any other INVITE would be. It eventually "rives at a 
presence server, which can either terminate the Ascription (in 
which case it acts as the presence agent for the P"<?entity) . or 
proxy it on to a presence client. If the presence client handles the 
Kription, it is effectively acting as the the 
presentity. The decision about whether to proxy or terminate the 
^SCRIBE is a local matter; however, we describe one way to effect 
such a configuration, using REGISTER. 

The oresence agent (whether in the presence server or presence 
cUen" SSt authenticates the subscription, then authorizes it^ Th e 
means for authorization are outside the scope of ^is protocol and 
we expect that many mechanisms will be used. Once authorized, the 
presence agent senas a 202 Accepted response. It also sends an 
immediate NOTIFY meseage containing the state of the P^tity . As 
cnVstate of the presentity changes, the PA generates NOTIFY for all 
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subscribers . 

The SUBSCRIBE message effectively establishes a session with the 
presence agent. As a result, the SUBSCRIBE can be record -routed, and 
rules for tag handling and Contact processing mirror those for 
INVITE. Similarly, the NOTIFY message is handled in much the same way 
a re -INVITE within a call leg is handled. 

4 Naming 

A presentity is identified in the most general way through a presence 
URI [41, which is of the form pres :user@domain. These URIs are 
protocol independent. Through a variety of means, these URIs can be 
resolved to determine a specific protocol that can be used to access 
the presentity. Once such a resolution has taken place, the 
presentity can be addressed with a sip URL of nearly identical form: 
sip:user@domain. The protocol independent form (the pres: URL) can be 
thought of as an abstract name, akin to a URN, which is used to 
identify elements in a presence system. These are resolved to 
concrete URLs that can be used to directly locate those entities on 
the network. 

When subscribing to a presentity, the subscription can be addressed 
using the protocol independent form or the sip URL form. In the SIP 
context, "addressed" refers to the request URI. It is RECOMMENDED 
that if the entity sending a SUBSCRIBE is capable of resolving the 
protocol independent form to the SIP form, this resolution is done 
before sending the request. However, if the entity is incapable of 
doing this translation, the protocol independent form is used in the 
request URI. Performing the translation as early as possible means 
that these requests can be routed by SIP proxies that are not aware 
of the presence namespace.. 

The result of this naming scheme is that a SUBSCRIBE request is 
addressed to a user the exact same way an INVITE request would be 
addressed. This means that the SIP network will route these messages 
along the same path an INVITE would travel . One of these entities 
along the path may act as a PA for the subscription. Typically, this 
will either be the presence server (which is the proxy/ registrar 
where that user is registered) , or the presence client (which is one 
of the user agents associated with that presentity) . 

SUBSCRIBE messages also contain logical identifiers that define the 
originator and recipient of the subscription (the To and From header 
fields) . Since these identifiers are logical ones, it is RECOMMENDED 
that these use the protocol independent format whenever possible. 
This also makes it easier to interwork with other systems which 
recognize these forms. 
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The Contact, Record-Route and Route fields do not identify logical 
entities, but rather concrete ones used for SIP messaging. As such, 
they MUST use the SIP URL forms in both SUBSCRIBE and NOTIFY. 

5 Presence Event Package 

The SIP event framework [3] defines an abstract SIP extension for 
subscribing to, and receiving notifications of, events. It leaves the 
definition of many additional aspects of these events to concrete 
extensions, also known as event packages. This extension qualifies as 
an event package. This section fills in the information required by 
[31. 

5.1 Package Name 

The name of this package is "presence". This name MUST appear within 
the Event header in SUBSCRIBE request and NOTIFY request. This 
section also serves as the I ANA registration for the event package 
"presence" . 

TODO: Define I ANA template in sub-notify and fill it in here. 
Example : 



Event: presence 



5.2 SUBSCRIBE bodies 

The body of a SUBSCRIBE request MAY contain a body. The purpose of 
the body depends on its type. In general, subscriptions will normally 
not contain bodies. The request URI, which identifies the presentity, 
combined with the event package name, are sufficient for user 
presence. 

Me anticipate that document formats could be defined -to act as 
filters for subscriptions. These filters would indicate certain user 
presence events that would generate notifies, or restrict the set of 
data returned in NOTIFY requests. For example, a presence filter 
might specify that the notifications should only be generated when 
the status of the users instant message inbox changes. It might also 
say that the content of these notifications should only contain the 
IM related information. 

5.3 Expiration 
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User presence changes as a result of events that include: 

o Turning on and off of a cell phone 

o Modifying the registration from a softphone 

o Changing the status on an instant messaging tool 

These events are usually triggered by human intervention, and occur 
with a frequency on the order of minutes or hours. As such, it is 
subscriptions should have an expiration in the middle of this range 
which is roughly one hour. Therefore, the default W»ti~ time for 
subscriptions within this package is 3600 seconds. As per [3] the 
subscriber MAY include an alternate expiration time . ^™» r J* e 
indicated expiration time, the server MAY reduce it but MUST NOT 
increase it. 

5.4 NOTIFY Bodies 

The body of the notification contains a presence document. This 
document describes the user presence of the P™" ntit y rmat 
subscribed to. All subscribers MUST support the £J» 'f^L 

described in [fill in with IMPP document TBD] , and MUST list its MIME 
type, [fill in with MIME type] in an Accept header present in the 
SUBSCRIBE request. 

Other presence data formats might be defined in the future. In that 
case, the subscriptions MAY indicate support for other presence 
formats. However, they MUST always support and list [fill in witn 
MIME type of IMPP presence document) as an allowed format. 

Of course, the notifications generated by the presence agent MUST be 
in one of the formats specified in the Accept header in the SUBSCRIBE 
request . 

5.5 Processing Requirements at the PA 

user presence is highly sensitive information. Because the 
implications of divulging presence information oan be ^ere. strong 
requirements are imposed on the PA regarding subscription processing, 
especially related to authentication and authorization. 

A presence agent MUST authenticate all subscription requests. This 
authentication can be done using any of the mechanisms defined for 
SIP It is not considered sufficient for the authentication to be 
transitive; that is. the authentication SHOULD use an end-to-end 
mechanism. The SIP basic authentication mechanism MUST NOT be used. 
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It is RECOMMENDED that any subscriptions that are not authenticated 
do not cause state to be established in the PA. This can be 
accomplished by generating a 401 in response to the SUBSCRIBE, and 
then discarding all state for that transaction. Retransmissions of 
the SUBSCRIBE generate the same response, guaranteeing reliability 
even over UDP. 

Furthermore, a PA MUST NOT accept a subscription unless authorization 
has been provided by the presentity. The means by which authorization 
are provided are outside the scope of this document. Authorization 
may have been provided ahead of time through access lists, perhaps 
specified in a web page. Authorization may have been provided by 
means of uploading of some kind of standardized access control list 
document. Back end authorization servers, such as a DIAMETER [5], 
RADIUS {6], or COPS [7], can also be used. It is also useful to be 
able to query the user for authorization following the receipt of a 
subscription request for which no authorization information was 
present. Appendix A provides a possible solution for such a scenario. 

The result of the authorization decision by the server will be 
reject, accept, or pending. Pending occurs when the server cannot 
obtain authorization at this time, and may be able to do so at a 
later time, when the presentity becomes available. 

Unfortunately, if the server informs the subscriber that the 
subscription is pending, this will divulge information about the 
presentity - namely, that they have not granted authorization and are 
not available to give it at this time. Therefore, a PA SHOULD 
generate the same response for both pending and accepted 
subscriptions. This response SHOULD be a 202 Accepted response. 

If the server informs the subscriber that the subscription is 
rejected, this also divulges information about the presentity - 
namely, that they have explicitly blocked the subscription 
previously, or are available at this time and chose to decline the 
subscription. If the policy of the server is not to divulge this 
information, the PA MAY respond with a 202 Accepted response even 
though the subscription is rejected. Alternatively, if the policy of 
the presentity or the PA is that it is acceptable to inform the 
subscriber of the rejection, a 603 Decline SHOULD be used. 

Note that since the response to a subscription does not contain any 
useful information about the presentity, privacy and integrity of 
SUBSCRIBE responses is not deemed important. 

5.6 Generation of Notifications 

Upon acceptance of a subscription, the PA SHOULD generate an 
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immediate NOTIFY with the current presence state of the presentity. 

If a subscription is received, and is ™™ ™ IFy 
re-iected the PA SHOULD generate an immediate NOTIFY. This notifx 
snouS contain a valid state for the presentity, yet be one which 
provides no useful information about the P"**^^.^ 
this is to provide an IM URL that is the same form as the presence 
£l and mar* that IM address as -not available-^ The reason or this 
Socess of -lying- is that without it, a subscriber could tell the 
difference between a pending subscription and an accepted 
sioscription based on the existence and content of an immediate 
NOTIFY ae approach defined here ensures that the presence delivered 
in a NOTIFY generated by a pending or rejected subscription is also a 
JaUd onfchat could have been delivered in a NOTIFY generated by an 
accepted subscription. 

If the policy of the presence server or the presentity is that it is 
acceptable to divulge information about whether the subscription 
succeeded or not, the immediate NOTIFY need not be sent for pending 
or rejected subscriptions. 

Of course, once a subscription is accepted, the PA SHOULD generate a 
notify for the subscription when it determines that the presence 
SlceVf che presentity has changed. Section 6 describes how the PA 
makes this determination. 

For reasons of privacy, it will frequently be necessary ^encrypt 
the contents of the notifications. This can be accomplished using the 
standard SIP encryption mechanisms. The encryption sh °uld be 
Performed using the key of the subscriber as ^^"^.^'^^ 
field of the SUBSCRIBE. Similarly, integrity of the notif 
important to subscribers. As such, the contents of ^e notifications 
£ be authenticated using one of the standardised mechanisms. 
Since the NOTIFY are generated by the presence server, which may not 
have access^o the key of the user represented by the PJ"«£j£ lt 
will freouently be the case that the NOTIFY are signed by a third 
party iHf RECOMMENDED that the signature be by an authority over 
domain of the presentity. In other words for a user 
pres: user@example.com, the signator of the NOTIFY SHOULD be the 
authority for example.com. 

5.7 Rate Limitations on NOTIFY 

For reasons of congestion control, it is important that^^^Mte^of 
notifications not become excessive. As a result, it is 
that the PA not generate notifications for a single presentity at a 
rate faster than once every 5 seconds. 
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5.8 Refresh Behavior 

Since SUBSCRIBE is routed by proxies as any other method, it is 
possible that a subscription might fork. The result is that it might 
arrive at multiple devices which are configured to act as a PA for 
the same presentity. Each of these will respond with a 202 response 
to the SUBSCRIBE . Based on the forking rules in SIP, only one of 
these responses is passed to the subscriber. However, the subscriber 
will receive notifications from each of those PA which accepted the 
subscriptions. The SIP event framework allows each package to define 
the handling for this case. 

The processing in this case is identical to the way INVITE would be 
handled. The 202 Accepted to the SUBSCRIBE will result in the 
installation of subscription state in the subscriber. The 
subscription is associated with the To and From (both with tags) and 
Call-ID from the 202. When notifications arrive, those from the PA's 
whose 202 «s were discarded in the forking proxy will not match the 
subscription ID stored at the subscriber (the From tags will differ) . 
These SHOULD be responded to with a 481. This will disable the 
subscriptions from those PA. Furthermore, when refreshing the 
subscription, the refresh SHOULD make use of the tags from the 202 
and make use of any Contact or Record-Route headers in order to 
deliver the SUBSCRIBE back to the same PA that sent the 202. 

The result of this is that a presentity can have multiple PAs active, 
but these should be homogeneous, so that each can generate the same 
set of notifications for the. presentity . Supporting heterogeneous 
PAs, each of which generated notifications for a subset of the 
presence data, is complex and difficult to manage. If such a feature 
is needed, it can be accomplished with a B2BUA rather than through a 
forking proxy. 

6 Publication 

The user presence for a presentity can be obtained from any number of 
different ways. Baseline SIP defines a method that is used by all SIP 
clients - the REGISTER method. This method allows a UA to inform a 
SIP network of its current communications addresses (ie., Contact 
addresses) . Furthermore, multiple UA can independently register 
Contact addresses for the same SIP URL. These Contact addresses can 
be SIP URLs, or they can be any other valid URL. 

Using the register information for presence is straightforward. The 
address of record in the REGISTER (the To field) identifies the 
presentity. The Contact headers define communications addresses that 
describe the state of the presentity. The use of the SIP caller 
preferences extension [8] is RECOMMENDED for use with UAs that are 
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interested in presence. It provides additional information about the 
Contact addresses that can be used to construct a richer presence 
document. The "description" attribute of the Contact header is 
explicitly defined here to be used as a free -form field that allows a 
user to define the status of the presentity at that communications 
address . 

We also allow REGISTER requests to contain presence documents, so 
that the PUAs can publish more complex information. 

Note that we do not provide for locking mechanisms, which would allow 
a client to lock presence state, fetch it, and update it atomically. 
We believe that this is not neeeded for the majority of use cases, 
and introduces substantial complexity. Most presence operations do 
not require get-before-set, since the SIP register mechanism works in 
such a way that data can be updated without a get. 

The application of registered contacts to presence increases the 
requirements for authenticity. Therefore, REGISTER requests used by 
presence user agents SHOULD be authenticated using either SIP 
authentication mechanisms, or a hop by hop mechanism. 

To indicate presence for instant messaging, the UA MAY either 
register contact addresses that are SIP URLs with the "methods" 
parameter set to indicate the method MESSAGE, or it MAY register an 
IM URL. 

TODO: This section needs work. Need to define a concrete example of 
mapping a register to a presence document, once IMPP generates the 
document format. 

6.1 Migrating the PA Function 

It is important to realize that the PA function can be colocated with 
several elements: 

o It can be co- located with the proxy server handling 

registrations for the presentity. In this way, the PA knows 
the presence of the user through registrations. 

o It can be co- located with a PUA for that presentity. In the 
case of a single PUA per presentity, the PUA knows the state 
of the presentity by sheer nature of its -co-location. 

o It can be co-located in any proxy along the call setup path. 
That proxy can learn the presence state of the presentity by 
generating its own SUBSCRIBE in order to determine it. In this 
case, the PA is effectively a B2BUA. 
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Because of the soft -state nature of the subscriptions, it becomes 
possible for the PA function to migrate during the lifetime of a 
subscription. The most workable scenario is for the PA function to 
migrate from the presence server to the PUA, and back. 

Consider a subscription that is installed in a presence server. 
Assume for the moment that the presence server «n determine that a 
downstream UA is capable of acting as a PA for the presentity. When a 
subscription refresh arrives, the PA destroys its subscription, and 
then acts as a proxy for the subscription. The subscription is then 
routed to the UA, where it can be accepted. The result is that the 
subscription becomes installed in the PUA. 

For this migration to work, the PUA MUST be prepared to accept 
SUBSCRIBE requests which already contain tags in the To field. 
Furthermore, the PUA MUST insert a Contact header into the 202, and 
this header MUST be used by the subscriber to update the contact 
address for the subscription. 

TODO: Does this work? What about getting a Record-Route in place at 
the PUA. This might only be possible for refreshes that don't use 
Route or tags. 

The presence server determines that a PUA is capable of supporting a 
PA function through the REGISTER message. Specifically, if a PUA 
wishes to indicate support for the PA function, it SHOULD include a 
contact address in its registration with a caller preferences 
"methods" parameter listing SUBSCRIBE. 

7 Mapping to CPIM 

This section defines how a. SIP for presence messages are converted to 
CPIM, and how a CPIM messages are converted -to SIP for presence. SIP 
to CPIM conversion occurs when a SIP system sends a SUBSCRIBE request 
that contains a pres URL or SIP URL that corresponds to a user in a 
domain that runs a different presence protocol. CPIM to SIP involves 
the case where a user in a different protocol domain generates a 
subscription that is destined for a user in a SIP domain. 

Note that the process defined below requires that the gateway store 
subscription state. ThiB unfortunate result is due to the need to 
remember the Call-ID, CSeq. and Route headers for subscriptions from 
the SIP side, so that they can be inserted into the SIP NOTIFY 
generated when a CPIM notification arrives. 

7.1 SIP to CPIM 

SIP for presnce is converted to CPIM through a SIP to CPIM abstract 
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gateway service, depicted in Figure 1. 



+ + 

| I 
SIP to CPIM| 
Conversion 



SIP 



CPIM 



Figure X: SIP to CPIM Conversion 



The first step is that a SUBSCRIBE request is received at a gateway. 
The gateway generates a CPIM subscription request, wxth xts 
parameters filled in as follows: 

o The watcher identity in the CPIM message is copied from the 
SLn field of the SUBSCRIBE. If the From field contains a SIP 
UrT it is converted to an equivalent pres URL by dropping all 
SIP* URL parameters, and changing the scheme to pres. 



This conversion may not work - what if the SIP URL has 
no user name. Plus, converting from a URL back to a 
URN in thiB fashion may not do it correctly. 
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o The target identity in the CPIM message is copied from the 
ReaUst-URI field of the SUBSCRIBE . This may need to be 
converted to a prea URL as well. 

o The duration parameter in the CPIM message is copied from the 

the gateway. If no Expires header is present, one hour as 
assumed. 

witninlhe Yl5 network that may arrive at the same gateway. 

response to the SUB SCRI BE. It aa y £iei<j ^ ^ 

response, which is the same as header< which is 

response. The 202 response C ^™ M re quest. It is important 
the value of the target * rOT J h ^ S "?f Jarcet ^Ince that makes sure 
that the Contact header be set to £he target. J«« as 

response. 

^HLXoPFC*"! ^ ^oceXrcs «or constructing « »=».« 
»""» SS will U.ult in the To tield containing the 

"TSJS "£™t S^LS.* Z&S'SJ.tS Mr 
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is selected and stored. 

SUBSCRIBE refreshes are handled identically to initial subscriptions 
as above. 

If a subscription is received with an Expires of zero, the SIP to 
CPIM gateway generates an unsubscribe message into the the CPIM 
system. The watcher parameter is copied from the From field of the 
SUBSCRIBE. The target parameter is copied from the Request URI field 
of the SUBSCRIBE. The transID is copied from the tag in the To field 
of the SUBSCRIBE request. 

The response to an unsubscribe is either success or failure. In the 
case of success, a 202 response is constructed in the same fashion as 
above for a success response to a CPIM subscriber. All subscription 
state is removed. In the case of failure, a 603 response is 
constructed in the same fashion as above, and then subscription state 
is removed, if present. 

1:2 CPIM to SIP 

CPIM to SIP conversion occurs when a CPIM subscription request 
arrives on the CPIM side of the gateway. This scenario is shown in 
Figure 2 . 

The CPIM subscription request is converted into a SIP SUBSCRIBE 
request. To do that, the first step is to determine if the subscribe 
is for an existing subscription. That is done by taking the target in 
the CPIM subscription request, and matching it against targets for 
existing subscriptions. If there are none, it is a new subscription, 
otherwise, its a refresh. . 

If its a new subscription, the gateway generates a SIP SUBSCRIBE 
request in the following manner: 

o The From field in the request is set to the watcher field in 
the CPIM subscription request 

o The To field in the request is set to the target field in the 
CPIM subscription request 

o The Expires header in the SUBSCRIBE request is set <to the 
duration field in the CPIM subscription request 

o The tag in the From field is set to the trans ID in the -CPIM 
subscription request. 



Rosenberg et al. 



[Page 14] 



WO 02/096128 



PCT7IB02/02212 



28 



Internet Draft 



presence 



March 2, 2001 



SIP SUBSCRIBE 




CPIM subscription request 
> 



Figure 2: CPIM to SIP Conversion 



This SUBSCRIBE message is then sent. 

If the subscription is a refresh, a SUBSCRIBE request is generated in 
the same way. However, there will also be a tag in the To field, 
copied from the subscription state in the gateway, and a Route 
header, obtained from the subscription 6tate in the gateway. 

When a response to the SUBSCRIBE is received, a response is sent to 
the CPIM system. The duration parameter in this response is copied 
from the Expires header in the SUBSCRIBE response (a conversion from 
an absolute time to delta time may be needed) . The transID in the 
response is copied from the tag in the From field of the response. If 
the response was 202, the status is set to indeterminate. If the 
response was any other 200 class response, the status is set to 
sucess. For any other final response, the status is set to failure. 

If the response was a 200 class response, subscription state is 
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established. This state contains the tag from the To field in the 
SUBSCRIBE response, and the Route header set computed from the 
Record-Routes and Contact headers in the 200 class response. The 
subscription is indexed by the presentity identification (the To 
field of the SUBSCRIBE that was generated) . 

If an unsubscribe request is received from the CPIM side, the gateway 
checks if the subscription exists. If it does, a SUBSCRIBE is 
generated as described above. However, the Expires header is set to 
zero. If the subscription does not exist, the gateway generates a 
failure response and sends it to the CPIM system. When the response 
to the SUBSCRIBE request arrives, it is converted to a CPIM response 
as described above for the initial SUBSCRIBE response. In all cases, 
any subscription state in the gateway is destroyed. 

When a NOTIFY is received from the SIP system, a CPIM notification 
request is sent. This notification is constructed as follows: 

o The CPIM watcher is set to the URI in the To field of the 
NOTIFY. 

o The CPIM target is set to the URI in the From field of the 
NOTIFY. 

o The trans ID is computed using the same mechanism as for the 
SUBSCRIBE in Section 7.1 

o The presence component of the notification is extracted from 
the body of the SIP NOTIFY request. 

The gateway generates a 200 response to the SIP NOTIFY and sends it 
as well. 

TODO: some call flow diagrams with the parameters 
8 Firewall and NAT Traversal 

It is anticipated that presence services will be used by clients and 
presentities that are connected to proxy servers on the other side of 
firewalls and NATS. Fortunately, since the SIP presence messages do 
not establish independent media streams, as INVITE does, firewall and 
NAT traversal is much simpler than described in 1$) and {10] . 

Generally, data traverses NATs and firewalls when it is sent over TCP 
or TLS connections established by devices inside the f irewall/NAT to 
devices outside of it. As a result, it is RECOMMENDED that SIP for 
presence entities maintain persistent TCP or TLS connections to their 
next hop peers. This includes connections opened to send a SUBSCRIBE, 
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NOTIFY and most importantly, REGISTER. By keeping the latter 
connecUon open, it can be used by the SIP proxy to send messages 
frSrouisJdfth; firewall/NAT back to the client It is also 
rrom client include a Contact cookie as described in 

^SH^l^^ES solhat the proxy can map the presentity 
URI to that connection. 

Furthermore, entities on either side of a firewall or MAT should 
t^d-route in order to ensure that the initial connection 
estabtishea for III subscription is used for the notifications as 
well. 

9 Security considerations 

There are numerous security considerations for Presence^ Many are 
outlined above; this section considers them issue by issue. 



9.1 Privacy 

Privacy encompasses many aspects of a presence system: 

o Subscribers may not want to reveal the fact that they have 
subscribed to certain users 

o Users may not want to reveal that they have accepted 
subscriptions from certain users 

o Notifications (and fetch results) may ^"J" 6 ^^^^ 3 
which should not be revealed to anyone but the subscriber 

Privacy is provided through a combination of hop by hop encryption 
S ind to end encryption. The hop by hop mechanisms provide scalable 
Svacy services, disable attacks involving traffic analysis, and 
nSe all aspects' of presence messages. H^-^^^S.? 1 " 
transitivity of trust, and they cause message content to be reyeaiea 
11 nroxies The end-to-end mechanisms do not require transitivity of 
cruse anu'rlvearinrormation only to the desired recipient. However 
S-to-end encryption cannot hide all information, and is mtdU 
!«%r*«ie analvsiB Strong end to end authentication and encryption 
Sso requir^cSt botn participants have public keys, which is not 
generally the case. Thus, both mechanisms combined are needed for 
complete privacy services. 

SIP allows any hop by hop encryption scheme. It is RE 
between network servers (proxies to proxies, proxies ^ redirect 
servers), transport mode ESP [111 is used to encrypt the entire^ 
message. Between a UAC and its local proxy. TLS [12) is ^"TfX 
Similarly, TLS SHOULD be used between a presence server and the PUA. 
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The presence server can determine whether TLS is supported by the 
receiving client based on the transport parameter in the Contact 
header of its registration. If that registration contains the token 
M tls" as transport, it implies that the PUA supports TLS. 

Furthermore, we allow for the Contact header in the SUBSCRIBE request 
to contain TLS as a transport. The Contact header is used to route 
subsequent messages between a pair of entities. It defines the 
address and transport used to communicate with the user agent. Even 
though TLS might be used between the subscriber and its local proxy, 
placing this parameter in the Contact header means that TLS can also 
be used end to end for generation of notifications after the initial 
SUBSCRIBE message has been successfully routed. This would provide 
end to end privacy and authentication services with low proxy 
overheads . 

SIP encryption MAY be used end to end for the transmission of both 
SUBSCRIBE and KOTIFY requests. SIP supports PGP based encryption, 
which does not require the establishment of a session key for 
encryption of messages within a given subscription (basically, a new 
session key is established for each message as part of the PGP 
encryption) . Work has recently begun on the application of S/MIME 
[13] for SIP. 

9.2 Message integrity and authenticity 

It is important for the message recipient to ensure that the message 
contents are actually what was sent by the originator, and that the 
recipient of the message be able to determine who the originator 
really is. This applies to both requests and responses of SUBSCRIBE 
and NOTIFY. This is supported in SIP through end to end 
authentication and message integrity. SIP provides PGP based 
authentication and integrity (both challenge -response and public key 
signatures) , and http basic and digest authentication. HTTP Basic is 
NOT RECOMMENDED. 

9.3 Outbound authentication 

When local proxies are used for transmission of outbound messages, 
proxy authentication is RECOMMENDED. This is useful to verify the 
identity of the originator, and prevent spoofing and spawning at the 
originating network. 

9.4 Replay prevention 

To prevent the replay of old subscriptions and notifications, all 
signed SUBSCRIBE and NOTIFY requests and responses MUST contain a 
Date header covered by the message signature. Any message with a date 
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older than several minutes in the past, or more than several minutes 
into the future, SHOULD be discarded. 

Furthermore, all signed SUBSCRIBE and NOTIFY requests MUST contain a 
Call-ID and CSeq header covered by the message signature. A user 
agent or presence server MAY store a list of Call-ID values, and for 
each, the higest CSeq seen within that Call -ID. Any message that 
arrives for a Call-ID that exists, whose CSeq is lower than the 
highest seen so far, is discarded. 

Finally, challenge -response authentication (http digest or PGP) MAY 
be used to prevent replay attacks. 

9.5 Denial of service attacks 

Denial of service attacks are a critical problem for an open, inter- 
domain, presence protocol. Here, we discuss several possible attacks, 
and the steps we have taken to prevent them. 

9.5.1 Smurf attacks through false contacts 

Unfortunately, presence is a good candidate for smurf ing attacks 
because of its amplification properties. A 6ingle SUBSCRIBE message 
could generate a nearly unending stream of notifications, so long as 
a suitably dynamic source of presence data can be found. Thus, a 
simple way to launch an attack is to send subscriptions to a large 
number of users, and in the Contact header (which is where 
notifications are sent), place the address of the target. 

The only reliable way to prevent these attacks is through 
authentication and authorization. End users will hopefully not accept 
subscriptions from random unrecognized users. Also, the presence 
client software could be programmed to warn the user when the Contact 
header in a SUBSCRIBE is from a domain which does not match that of 
the From field (which identifies the subscriber) . 

Also, note that as described in 13] , if a NOTIFY is not acknowledged 
or was not wanted, the subscription that generated it is removed. 
This eliminates the amplification properties of providing false 
Contact addresses. 

10 Example message flows 

The following subsections exhibit example message flows, to further 
clarify behavior of the protocol. 

10.1 Client to Client Subscription with Presentity State Changes 
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This call flow l»u.«a«. —H"- and n««U«i». that do 
not involve a presence server. 

^ «^<a B( antitv. and the subscription is 
The watcher subscribes "Jf^S ' The P" 8entity 

accepted, resulting in a 202 Ac ceptea resulti in a new 

rjnM tL watcher cancelin9 the 

subscription. 



Watcher 



Present ity 



Fl SUBSCRIBE 
F2 202 .Accepted 
F3 NOTIFY 
F4 200 OK 
FS NOTIFY 
F6 200 OK 

F7 SUBSCRIBE (unsub) 
F8 202 Accepted 



Message Details 



Fl SUBSCRIBE watcher -> preeentity 



SUBSCRIBE sip :presentiWres .ml* . J- |IP/2 . 0 
Via- SIP/2. 0/UDP watcherhost. example. conusor 
Prftffl . Us er <pres:user@example.com> 
To^ Resource <pres . present ity^xample.^ 
Sll-ID : 3248543®watcherhost . example .com 
CSeq : 1 SUBSCRIBE 
Expires: 600 

Accept: application/xpidf«ml 
VoT^Z ~ser^atcherhost . exa^le .co. 
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F2 202 Accepted presentity->watcher 
SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP wat cherhost.example.com: 5 060 

From: User <pres:user@example.com> 

To: Resource <pres : pre sent ityOexample .com>; tag=i 

Call- ID: 3248543 ©wat che rhos t . example .com 

Cseq: 1 SUBSCRIBE 

Event: presence 

Expires: 600 

Contact : sip : present ity@pres .example .com 



F3 NOTIFY Presentity->watcher 

NOTIFY sip: user@watcherhost.example.com SIP/2.0 

Via: SIP/2. 0/UDP pre s .example. com: S060 

From: Resource <pres : present! tyOexample .com>; tag=88a7s 

To: User <pres : user@example.com> 

Call -ID : 3248543@watcherhost . example . com 

CSeq: 1 NOTIFY 

Event: presence 

Content -Type: application/xpidf +xml 
Content-Length: 120 

<?xml version- "l.a n ?> 

<presence entityInfo« n pres : present ity@example. com »> 

<tuple destination»«sip:presentity®example.com« status«"open /> 

</presence> 



F4 200 OK watcher- >presentity 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pres .example. com: 5060 
From: Resource <pres :presentity@example-com> 
To: User <pres:user@example.com> 
Call-ID: 324854 3@wa t cher hos t . exampl e .com 
CSeq: 1 NOTIFY 
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F5 NOTIFY Present ity->watcher 

NOTIFY sip: ueer@watcherhost.exatnple.com SIP/2.0 
Via; SIP/2. 0/UDP pres.example.com: 5060 
From: Resource <pres : present ity@example . com> 
To: User <pres :user@example . com> 
Call-ID: 3248S43@watcherhost.example.com 

CSeq: 2 NOTIFY 
Event: presence 

Content-Type: application/xpidf+xml 
Content -Length: 120 

<?xml version= n 1.0 n ?> 

<presence entityInfo="pres rpresenti ty@example.com" > 

<tuple destination= M sip:presentity@example.<:om« status="closed«/> 

</presence> 



F6 200 OK watcher- >presentity 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pres. example. com: 5060 
From: Resource <pres :presentity@example .com> 
To : User <pres : user@example . com> 
Call - ID : 324 6543@watcherhost . example . com 
CSeq: 2 NOTIFY 



F7 SUBSCRIBE watcher -> present ity 

SUBSCRIBE sip:presentity@pres. example. com SIP/2.0 

Via: SIP/2. 0/UDP watcherhost. example .com:5060 

From: User <pres : user@example.com> 

To: Resource <pres : presentity@example.com> 

Call -ID: 3248543®watcherhost. example ;*com 

Event : presence 

CSeq : 2 SUBSCRIBE 

Expires: 0 

Accept: application/xpidf+xml 

Contact : sip : user@watcherhost . example . com 
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F8 202 Accepted presentity->watcher 
SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP watcherhost.example.com: 5060 

From: User <pres :user@example .com> 

To: Resource <p res : pre sent ity®example .com> 

Cal 1 - ID : 3 24 854 3©watcherhost . example . com 

Event: presence 

Cseq: 2 SUBSCRIBE 

Expires : 0 



10.2 Presence Server with Client Notifications 



This call flow shows the involvement of a presence server in the 
handling of subscriptions. In this scenario, the client has indicated 
that it will handle subscriptions and thus notifications. The message 
flow shows a change of presence state by the client and a 
cancellation of the subscription by the watcher. 



Watcher 



F3 SUBSCRIBE 



Presence 
Server 

Fl REGISTER 

< 

F2 200 OK 



PUA 







F4 SUBSCRIBE 






F5 202 




F6 202 








F7 NOTIFY 






F8 200 OK 


1 








F9 REGISTER 








F10 200 OK 




Fll NOTIFY 
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| F12 200 OK I 



MeBsage Details 



Fl REGISTER PUA->server 

REGISTER sip: example. com SIP/2.0 
Via: SIP/2. 0/UDP pua.example.com: 5060 
To: <sip:resource@example.com> 
From: <sip:resource®example.com> 
Call-ID: 2818®pua.example.com 

Con?ac^ R <fi^ e pua.example.com>;methods a «MESSAGE. 

; description="open" -«iiacaiBB- 
Contact : <sip : id®pua . example . com> ; methods= "SUBSCRIBE 
Expires: 600 



F2 200 OK server->PUA 
SIP/2.0 200 OK 



SIP/2. u ^vw vr. 

Via: SIP/2. 0/UDP pua.example.com: 5060 
To : < s ip : resource@example . com> 
From: <sip:resource@example.com> 
Call -ID: 2818@pua.example.com 

CSeq: 1 REGISTER »mp«?SAGE " 

Contact : <sip : id®pua . example . com> ; methods- "MESSAGE 

• des crip t ion= "open" 
Contact : <sip : idSpua . example . com> ; methods=»SUBSCRIBE" 

Expires: 600 



F3 SUBSCRIBE watcher ->server 
Rosenberg et al. 
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SUBSCRIBE sip:resource©example.com 

Via: SIP/2. O/UDP watcherhost.example.com: 5060 

From: User <pres :user@example.com> 

To- Resource <pres : resource@example.com> 

Call-ID: 324 B5@wat cherhost . example . com 

CSeq : 1 SUBSCRIBE 

Expires: 600 

Event: presence 

Accept: application/xpidf+xml 

Contact : sip :user©vatcherhost . example . com 



F4 SUBSCRIBE server->PUA 

SUBSCRIBE sip: id@pua.example.com SIE> /2.0 
via: SIP/2. O/UDP server .example •comiSOeo 
via: SIP/2. O/UDP watcherhost.example.com. 5060 
From: User <pres :user@example.com> 
To- Resource <pres :resource®example.com> 
Call-ID: 32485@watcherhost.example.com 
CSeq : 1 SUBSCRIBE 
Event: presence 
Expires: 600 

Accept: application/xpidf+xml 

Contact : sip -.userowatcherhost . example .<:om 



F5 202 Accepted puA->server 
SIP/2.0 202 Accepted 

via: SIP/2. O/UDP server. example. com :S060 

via: SIP/2. O/UDP watcherhost. example. com:S060 

From: User <pres : user@example.com> 

To: Resource <pres : resource@example.com>; tag«f fd2 

Call -ID : 32485®watcherhost . example .com 

CSeq : 1 SUBSCRIBE 

Event: presence 

Expires: 600 
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F6 200 OK server- >watcher 
SIP/2.0 202 Accepted 

Via- SIP/2. 0/UDP watcherhost.exaraple.com: 5060 

From: User <pres: user@example.com> 

To Resource < P res:resource®example.com>;tag«ffd2 

Ca 1 1 - ID : 3248 5@wa t cherhos t . example .com 
CSeq : 1 SUBSCRIBE 
Event: presence 
Expires: 600 



F7 NOTIFY PUA->watcher 

NOTIFY sip: user@watcherhost.example.com SIP/2.0 
Via: SIP/2. 0/UDP pua .example .com: 5060 
To: User <pres: user@example.com> 

From: Resource <pres :resource®example.com>; tag=f fd2 

Cal 1-ID : 32485@watcherhost . example . com 

CSeq : 1 NOTIFY 

Event: presence • 

Content-Type: application/xpidf «ml 

Content -Length: 120 

</presence> 



F8 200 OK watcher- >PUA 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pua. example. com: 5060 
To: user <pres: user@example.com> 

From: Resource <pres:resource@example.com>;tagoffd2 
Call - ID : 32485@watcherhost . example .com 
CSeq : 1 NOTIFY 
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F9 REGISTER PUA->server 

REGISTER sip: example. com SIP/2.0 
Via: SIP/2. 0/UDP pua . example .com: 5060 
To: <sip:resource®example.com> 
From: <sip:resource@example.com> 
Call-ID: 2818@pua.example.com 

S?ac^^ I ip^a.exa ra ple.co ma;m ethods=.M E SS A G E .. 

; description=''busy eiTRQf BTBB " 

Contact : <8ip : id®pua . example . com> ;methods=»SUBSCRIBE 
Expires: 600 



F10 200 OK server->PUA 
SIP/2.0 200 OK 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pua.example.com: 5060 
To : < s ip : resour ceOexample . com> 
From: <sip:resource®example.com> 
Call-ID: 2818@pua. example. com 

Expires: 600 



Fll NOTIFY PUA->watcher 

NOTIFY sip: user@watcherhost.example.com SIP/2.0 
Via: SIP/2. 0/UDP pua. example .-com: 5 060 
To: User <pres :user@example .com> 

From: Resource <pres : resource @ example.com>;*ag-f f d2 
Call -ID : 32485@watcherhost . example . com 
CSeq : 2 NOTIFY 
Event: presence 

Content -Type: application/xpidf «cml 
Content -Length: 120 
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<?xml versions" 1 . 0 n ?> 

<presence ent ityInfo="pres : resource@example . corn 11 > 

<tuple destinations" im: resource@example.com" status«"busy"/> 
</presence> 



F12 200 OK watcher->PUA 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pua .example .com: 5060 
To: User <pres :user@example.com> 

From : Resource <pres : resource@example . com> ; tag=f f d2 
Call - ID : 3 2485@watcherhost . example . com 
CSeq : 2 NOTIFY 



10.3 Presence Server Notifications 

This message flow illustrates how the presence server can be the 
responsible for sending notifications for a presentity. The presence 
server will do this if the presentity has not sent a registration 
indicating an interest in handling subscriptions. This flow assumes 
that the watcher has previously been authorized to subscribe to this 
resource at the server. 



Watcher Server PUA 



Fl SUBSCRIBE 



> 



F2 202 Accepted 



< 



F3 NOTIFY 



< 



F4 200 OK 



> 



F5 REGISTER 



< 



F6 200 OK 



> 
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| F7 NOTIFY 



j F8 200 OK 



>l 



Message Details 

Fl SUBSCRIBE watcher- > server 



Expires: 600 



F2 202 OK server- >watcher 

SIP/2.0 202 Accepted 
Via: SIP/2. 0/UDP watcherhost.examp 
To : <pres : resource@example . com> ;ta 
From: <pres:user@example.com> 
Call-ID: 2010©watcherhost. example. 
CSeq: 1 SUBSCRIBE 
Event: presence 
Expires: 600 

Contact : s ip : example . com 



F3 NOTIFY server- > watcher 
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Prom: <pres : resource@example.com> ; tag=f fd2 

To: <pres: user@example.com> 

Call -ID = 2010®watcherhost . example . com 

Event: presence 

CSeq: 1 NOTIFY 

ConJent-Type: application/xpidf + xml 
Content -Length: 120 



<?xml ver8io "?"J:°^!„ Dre9 . re source®example.com-> 
^^de^nS^ status-open-^ 



</presence> 



F4 200 OK 

SIP/2.0 200 OK 



S SIP 2°0/GdP server.example.com:5060 
From : <pres : resourceSexample . com> ; tag-f f d2 

To: <pres:user@example.com> 

Call-ID: 2010®watcherhost. example. com 

CSeq: 1 NOTIFY 



F5 REGISTER 

REGISTER sip texample.com SIP/2.0 
Via: SIP/ 2. 0/UDP pua.example.com: 5 060 
To: <sip:resource®example.com> 
From: <sip:resource®example.com> 
Call-ID: il08pua.example.com 

Con?ac 2 t • -ample .com> f me thods.-MESSAGE" 

Contact. ;d P scri ^ tiona0Away from keyboard- 

Expires: 600 
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Via- SIP/2. 0/ODP pua. example. com :S060 
To • ' <s ip = resource©example ,com> 
?rom: 8 <;ip:resource e example n Com> 
Call-ID : 110«apua.example.com 

CSeq: 2 AGISTER exa _ le . CO m>;metbods=»MESSAGB" 
Contact: <»P;^ a ti :niay from Keyboard" 
. expires=600 



F7 NOTIFY 



NOTIFY sip :user*watc»erhost .example com SIP/2 
Via SIP/2 . 0/UDP server . example .com: 5060 
?rom <pres:resource« 5 )example.com>;tag=ffd2 

To- <pres:user«example.com> 

Sil-S : 2010®watcherhost . example . com 

CSeq: 2 NOTIFY 

Content -Length: 120 



keyboard" /> 

</presence> 



F8 200 OK 



VU-% 0 Ip"2%/^Pserver.example.com:S060 
F iom= <sip:resource e exam P le.com>;tag=ffd2 

To: <pres:user®example.com> 

Call-ID: 2010®watcherhost .example.com 

CSeq: 2 NOTIFY 
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11 Open issues 

The following i» the list of known op« i«a-< 

. This or.ft reco-oenos th« tto » «£» 

with pr.eence ^'.'"^J^i'it.^ftSie.J It th.ro toy 

. tot. u-fti- - ~ — tta " ^ *° " ^ * 

value? 5 seconds is arbitrary, 
o Merging of presence d.t. fro. -itipi. » he. been «~tod. » 
that OK? 

o naoin, » « i» contact header of . «am. 
OK? What does it mean? 

o T he process of 

to PUA is not likely to work in tne cas cho ice. 
refreshes use tags **™Zg*tf£'„ ^ep with leg oriented 

^i?^ chere 18 no ta98 

or Route's associated with subscriptions. 

o converting SIP URLs back to pres URLs. 

o The SIP to CPIM and CPIM to SIP f^™. 

because of the need to maintain ™£>J£\*% t \ M \ .token 

response. Would that help? 

o toed to epeoif, how to -^"00^"'" * 

presence document. One ° bviou ° x probably want to put 

•r.^r.-Soro.TtSrSrolIi.^ol, not go through 

the proxy. 

12 Changes from -00 

The document has been completely rewritten to reflect the^change 
from a sales pitch and ^^J^S^^ align with the 
S 'SSt'SSSS - Sh'S.rS. specific protocol changes 
resulting from this rewrite are: 
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o Th, Event he.d«r «.« — » «"* '« <~ sraSCMM ma NOTIFY 
requests . 

o The SUBSCRIBE message can only have a single Contact header. 

-00 allowed for more than one. 
o The From and To headers can contain presence URI.. 
o The Request -URI can contain a presence URI. 

o Subscriptions are responded to with a 202 if they are pending 
or accepted. 

o Authentication i. no. ™nd.tory « *"« »• ""K" 1 **"™ " 
now mandatory at the PA. 

o Fake NOTIFY is sent for pending or rejected subscriptions, 
o A rate limit on notifications was introduced, 
o Merging of presence data has been removed. 

o Th e subscriber r^^^^^^^S. 25 

particular subscriber for a particular presently, 
o IM URLs allowed in Contacts in register 
o CPIM mappings defined. 

o Persistent connections recommended for firewall traversal. 
Obtaining Authorization 

when a subscription arrives at a ^thejub ^ ave 
authorized by the P^sentity In some «ses ; the^ p y ^ 

the presentity for authorization. 
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subscriptions for presentity X", and the subscriber to that virtual 
presentity is X itself. Whenever a subscription iB received for X, 
the virtual presentity changes state to reflect the new subscription 
for X. This state changes for subscriptions that are approved and for 
ones that are pending. As a result of this, when a subscription 
arrives for which authorization is needed, the state of the virtual 
presentity changes to indicate a pending subscription. The entire 
state of the virtual presentity is then sent to the subscriber (the 
presentity itself) . This way, the user behind that presentity can see 
that there are pending subscriptions. It can then use some non-SIP 
means to install policy in the server regarding this new user. This 
policy is then used to either accept or reject the subscription. 

A call flow for this is shown in Figure 3. 



In the case where the presentity is not online, the problem is also 
straightforward. When the user log6 into their presence client, it 
can fetch the state of the virtual presentity for X, check for 
pending subscriptions, and for each of them, upload a new policy 
which indicates the appropriate action to take. 

A data format to represent the state of these virtual presentities 
can be found in [14] . 
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SUBSCRIBE X 
202 Accepted 



I 



HOT I FY X- subscriptions 



200 OK 



HTTP 



POST w/ policy 



200 OK 



Fi gure 3: Sequence diagram for online authorization 
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Foreword 

is Technical Report has been produced by the 3GPP. 



This Technical Kepon n» 5 u~.. »vi n the TSG and may change following formal 

Version x.y.z 
where: 

x the fust digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 



.he second digit is incremented for all changes of substance, 



i.e. technical enhancements, corrections, 



etc. 



the third digit is incremented when 



editorial only changes have been incorporated in the specification; 



1 Scope _ 

,••„«,„ all IP architecture option for release 00. The 
This technical report will propose an architecture mat provisions an all IP arch, 
^^lESKiiS and affected ongoingSGPPworkthatneedto be resolved and 



2 References 

non-specific. 

. For a specific reference, subsequent revisions do not apply. 

. Anon-specificreferenc.toanETSshallalsobetakentorefertolatervers 
number. 

[1] TS 22.101 version 3.6.0: Service Principles 

[2 ] TS 23.121: Architectural Requirements for Release 99. 



[3] 
14] 
{5] 



TS 22.121: The Virtual Home Environment 
TS 23 002: Network architecture 
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Definitions and abbreviations 



3.1 Definitions 



For the purposes of the present 



document, the [following] terms and definitions [given in 



. and the following] apply. 



existing service: services supported in Release 



99 and earlier releases for bothGSM and UMTS. 



All IP core network: core network of release 



2000 that uses IP for transport of all user date and signalling 



ERAN is defined as an evolved GSM BSS suppoi 
packet services 



.rring EDGE modulation schemes on a 200kHz basis and real time 



3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. 

<ACRONYM> . <Explanation> 
2Q second generation 

2Q third generation 



AMR 

AS 

BSC 

BTS 

CAMEL 

CAP 

CC 

CCF 

CN 

CS 

CSCF 

CSE 

DN 

DNS 

EDGE 

EGPRS 

FFS 

GGSN 

GMSC 

GPRS 

GSN 

GTP 

H-CSCF 

HN 

HSS 

ICGW 

IN 

INAP 
IP 

ISDN 

ISP 

1SUP 

LAN 

LN 

MAHO 
MAP 



Adaptive Multi Rate 
Application Server 
Base Station Controller 

££ ^Applications for Mobile Network Enhanced Logic 

CAMEL Application Part 

Call Control 

Call Control Function 

Core Network 

Circuit Switched 

Call State Control Function 

CAMEL Service Environment 

Directory Number 

Directory Name Server 

Enhanced Data for GSM 

Enhanced GPRS 

For Further Study 

Gateway GPRS Support Node 

Gateway MSC 

General Packet Radio Service 
GPRS Support Node 
GPRS Tunnelling Protocol 
Home CSCF 
Home Network 
Home Subscriber Server 
foconung Call Gateway 
Intelligent Network 
IN Application Part 
Internet Protocol 

Integrated Services Digital Network 

Internet Service Provider 

ISDN User Part 

Local Area Network 

Logical Name 

Mobile Assisted Handover 

Mobile Application Part 
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MCU 


Media Control Unit 


MExE 


Mobile Execution Environment 


MGCF 


Media Gateway Control Function 


MGW 


Media Gateway 


MM 


Mobility Management 


MO 


Mobile Originated 


MRF 


Media Resource Function 


MSC 


Mobile Switching Centre 


MT 


Mobile Termmated/Terminal 


NPA 


Numbering Plan Area 


O&M 


Operations and Maintenance 


ODB 


Operator Determined Barring 


OSA 


Open Service Architecture 


PCU 


Packet Control Unit 


PDP 


Packet Data Protocol 


PDU 


Packet Data Unit 


PS 


Packet Switched 


PSTN 


Public Switched Telephony Network 


QoS 


Quality of Service 


R00 


Release 2000 


R99 


Release 1999 


RA 


Routing Area 


RAN 


Radio Access Network 


RLC/MAC 


Radio Link Control/Media Access Control 


RNC 


Radio Network Controller 


R-SGW 


Roaming Signalling Gateway 


RTP 


Real Time Protocol 


SAT 


SIM Application Toolkit 


SCF 


Service Control Function (IN) and Service Capability Features (VHE/OSA) 


SCP 


Service Control Point 


S-CSCF 


Serving CSCF 


SGSN 


Serving GPRS Support Node 


SIP 


Session Initiated Protocol 


SLA 


Service Level Agreement 


SN 


Serving Network 


SRNC 


Serving Radio Network Controller 


SSF 


Service Switching Function 


TCP 


Transmission Control Protocol 


TE 


Terminal Equipment 


T-SGW 


Transport Signalling Gateway 


UDP 


User Datagram Protocol 


UE 


User Equipment 


UMS 


User Mobility Server 


UTRAN 


UMTS Terrestrial Radio Access Network 


VHE 


Virtual Home Environment 


VLR 


Visitor Location Register 


VoIP 


Voice over IP 


VPN 


Virtual Private Network 


WAP 


Wireless Application Protocol 


WIN 


Wireless IN (ANSI-4 1) 
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4 Requirements 
4.1 General 

2000, providing global terminal mobility (roaming) [1]. 

, M A p« axi an d UTRAN with a common core network, 
The IP network should provide w^less mobility acoe* > based «BJM ^HEAN ^ GSM based 

based an evolution of GPRS, for both. In ^^^^.^s a though EDGE is not within the scope of 
network supporting EDGE and evolved to ^'"^ P *S£L, to be common to both access technologies. 
3GPP, there are requirements for the core network of the all ir arennee 

The characteristics of this network are 

• Based on an evolution of GPRS 

. Common network elements for multiple access types including UTRAN and ERAN 

• Packet transport using IP protocols 

• IP Client enabled terminals 

. Supportforvoice.data.realtimemultimedia.andservice.wiA 
The report also covers the support of CS services on IP technologies. 
The benefits of this approach include 

used by subscribers whether accessing via conventional land telepnony, cam , 
. Synergy with generic IP developments and reduced cost of service 
. Efficicntsolunoa^^ 

• Higher level of control of services 

. Integrated, and cost reduced OA&M through IP 
. Takeadvantageoflntemetappl^ 

• Cost reduction through packet transport 



4 1 1 General Requirements 

, ' TheoveranalmortheaUIPnetworkistosuppons^ 

^ appropriate these services should inter-work with exisiting GSM services. 

, InaddidonitshouldaUopossibletosupp.^ 

multimedia, SMS. supplementary services. «J™d in such a way as to support interworking of 

(GSM pre Release 99, UMTS release 99). 
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3. The standard shall enable the all IP core network to support release 99 CS terminals. This shall be standardised in 
such a way as to allow operators to decide whether or not they wish to support Release 99 CS only terminals. 

4. The support of existing services shall not preclude the extension of service capabilities possible through the use of 
an all IP architecture. 

5. When the all IP networks are deployed, there will be services and databases provided for existing networks which 
are non-IP based e.g. local number portability, free phone numbers, specialised corporate services. The all IP 
architecture will need to be able to access these services. 

6. R'OO all IP core network shall allow implementations having a CS and a PS domain, that are separated like both 
these domains in the R'99 architecture. This implementation allows the two domains to evolve independently, e.g. 
to combine an all IP R'OO PS domain with a STM based R'99 CS domain. Furthermore it shall be possible to 
implement a CS domain that uses all IP based architecture and in distinct service areas of the same network a CS 
domain based on ATM/STM. This allows a smooth migration to an all IP based core network. 

The R'OO all IP architecture shall support that all services share bearer level transport and bearer control. 

R'OO architecture shaD allow an operator to migrate a R'99 network into a R'OO network, without need for change of 
transport network technology, node numbering scheme etc. R'OO networks shall also allow connection of R'99 
UTRAN over lues, to provide the operator with flexibility in the network implementation. 

Note: In the general R'OO architecture other transport technology than IP shall be possible. 



4.2 Service Capabilities 
4.2.1 General 

The following general service capabilities are identified: 

1. Legal interception has to be possible in the R00 All-IP network. 

2. Emergency calls shall be supported in the R00 All-IP network. 



4.2.2 Basic requirements for the Service and Application Platforms 

List of requirements on the "Application and Service" block: 

1. Service capabilities are to be made available to the Applications through Service capability features; 

2. Service capability features are provided by one or more service capabilities (possibly directly provided by 
network functions, e.g. HSS, CSCF etc.), as illustrated in Figure 4-1; 
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4. 



6. 
7. 
8. 



SCF1 SCF2 SCF3 



SCFn 



CSCF 



V) 



rr HSS 



& 
U 

4) 

1 



SGSN 



Service Capability Features 



Figure 4-1: Relationship between 



Service Capability Features (SCFs) and Service Capabilities. 



specific service capabilities; :„ tPT f flCe has to be introduced for access to Service capability 

by IT systems, through the service capability features. 



4 3 Numbering Schemes 

TbestandardsshaUailow^^ 

identifier e.g. MSISDN. This do«J»t precl^ n^Uple dependent upon, for 

5 to route based on a single identifier to mamtau. serv.ce transparency. 

4 4 R99 Terminals 

, The standards shall enable the All-IP core network to support UMTS R99 tenninals. 
supporting these services. 

3 To ensure roaming of non VoIP capable UMTS R99 tenninals, speech services including emergency^ shaU 
be possible based on CS capabilities of these terminals. 
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4.5 Radio aspects 

I The radio resource usage should be optimised within the architecture for both service and signalling support 
2 . Separation of the radio related and radio un-related functional between the core network and the radio access 
network 

3 Separation of the user plane and control plane protocol stacks in the radio access networks 

4. Fa* uplink access and fast resource assignment procedures in both uplink and downlink for multiplexing different 
types of traffic on the same air link. 

5 . Optimization of end-to-end IP transport for certain class of real time applications (e* header compression, header 
stripping) 

6 . Network controlled handover procedure with short interruption to support real time applications (see handover 
requirement, section 4.9.) 

7 Protocol stacks in the access network to support a range of services with different QoS requirements 

g. fcter-workmg^^^ 

mechanism used in the packet core network. 

o. Bearerdiffe^ 

maximum spectrum utilization 

10 Optimal coding and interleaving for some applications such as voice. 

1 1 . Support of multiple data flows with different QoS per IP address (as defined in QoS framework in release 99) 

12. Spectrum efficiency shall be maximized (e.g. statistical multiplexing). 

13. The ERAN shall support GPRS andEGPRS services for pre-Release 2000 terminals. 



4.6 Interworking 

! The AU-IP core network shall support interworking to externa. IP and non-IP networks (e.g. circuit-switched 
' networks (PSTN. ISDN, GSM PLMN, UMTS PLMN,...). 

4.7 Mobility management 

j The a „.ip core network shall provide streamlining and CN operated hand-over procedures for UMTS. 

4.8 Roaming 

Thestandardshallenableme^^ 
UMTS networks. 

4.9 Handover 

i ... qq r *i~,«. og an d release 2000 network technologies is essential in 

development of mechanisms. 

Table 4-1: Handover requirements for UMTS All IP network 
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Between 


2G-GSM cs 


2G-GPRS 


UMTS cs 
(R99) 


UMTSps 
(R99) 


UMTS IP 
(PS services) 


UMTS IP 
(CS 

services) 
"Not 


UMTS IP (PS 
services) 


ReqROO* 


ReqROO 


Req ROO* 


ReqROO 


OK 


Required 


UMTS IP (CS 
services) 


ReqROO 


NotReq 


ReqROO 


Not Req 


Not Req 


OK 



Key: 
OK 

ReqROO 



Same technology 

Required for release 2000 



♦ Theirnp^^^ 

for eitheTthe support of handover or to provide service coverage need to be investigated. 

4.9.1 Handover Categories 

1 Intra network handover 

Handover inside one all DP network 

1 a Intra RAN handover 
lb Inter RAN handover 

2 Inter network handover 

Handover between two all IP networks 

3 Inter-system handover 

Handover between an all IP network and other systems 



4 9 2 General Definition 

whereby the network determines which cell the mobue mil rece.vc semces on. 

4.9.3 General Requirements 

For real-time services handover procedure shall be used. The network shall control the handover procedure. 
Handover shall be the selected method of mobility if one or more active sessions have requested handover in a odd 
session call with different QoS requirements 

Performance requirement on speech interruption (i.e. W period) shall be equivakj, « ^better than than<3SM or 

!5sM36 handover for telephony services. TBD for other services offered by an all IP Network. 

Maintain maximum packet loss limit (i.e. less than TBD) and maximum delay limit (i.e., less than TBD) during 

handover. 

Non-real-time services shall use either handover or cel. reselection depending on the QoS parameters in combination 
with network parameters. 
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Handover procedure shall utilize radio resources efficiently. 

Handover shall not compromise the security of: ^ network proving Ae new radio resources; *e (possibly different) 
network providing the original radio resources; and the terminal UE. 

There shall be efficient handling of multiple bearers, e.g. if voice and email transfer is going on simultaneously. 
F^ntial IP/UDP/RTP header information (for inter and intra all IP network handover), as seen by an IP end point, shall 
£ p^XoXrer boundary. The required essential header information depends on the bearer. 

4.9.4 MS Requirements 

The mobile station shall be capable of supporting both selection and handover. 

The mobile station shall aid the RAN in the handover decision by supplying RF environmental information (e.g. 
received signal strength from serving cell and neighbour cells). 

4.9.5 RAN Requirements 

Handover decisions shall be based in the RAN. 

Maintain the RAN QoS parameters, associated with the mobile station, across a handover boundary. Note, RAN QoS 
ptSrslr a mobile station are based upon the negotiated set of QoS parameters. 

Facilitate admission control to optimize radio resources. 

Select a handover targe, based on criteria such as RF environmental information, radio resources of the neighboring 
cells, QoS requirements of the session, etc. 

4.10 Call Control and Roaming 

The following requirements need consideration for call control and roaming support in an all IP based network. 

1 Rouringofsignallingand^^ 
networks. 

2 Whenever possible, tromboning of the user's voice or data communkation ^-on back to theLr home environment 
3 not be used to provide the user with services when roaming outs.de their home network. 
The Release 2000 all IP network must comply with the mandated requirements for Emergency Services. 
The Release 2000 all IP network must comply with the mandated requirements for Number Portability. 

tt~ Release 2000 all IP network must support multiparty voice and data communications sessions including the 
c^SlryTor uTut or s^ce lo^to^nucally add or delete users from an active cornmurucations session. 

6 The Release 2000 all IP network must be able to accept and 

requests that are addressed to the user's directory number during periods of reaugnment of the national numoermg 
plans (e.g., NPA splits in North America). 

called and calling party have the same vocoder, no transcoding of the voice tratric, wiuun u» 

8 The Release 2000 all IP network must provide connection to the services of the legacy 2G and release 99 networks. 

9 The Release 2000 all IP network shall support VHE for roamers. 

10 Aminimumsetof services for roamers shall be provided within «h« ^'J^^^' 
services is still being defined. However, the following is anuc.pated to be ,n this rmnunal setofusersemces. 
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a Speech call and data session origination, 
b Speech call and data session termination, 
c Call Waiting for voice calls in the case of monomcdia session 
d Call Forwarding services for voice calls, 
e Calling party identification information 
f SMS 

be handled directly by the Release 2000 all IP networks: 

a Directory Assistance 

b Third party billing 

c Collect calls 

d Calling card calls 

12 When a Release 2000 all IP user roams from a Release 2000 all IP network to another 

12 wnen a Keie ^ w "" Mn<mort serv ices fe e GPRS) and application level services {e.g. multimedia calls), 
and gets access to both transport ^ ctwork or by a CSCF in the home network. The serving 

user's advanced/ supplementary services at the user's home network. 

13 The user shall be able to gain access to their ISPs or corporate LAN application level services. 

14 Both dynamic and dedicated IP addresses shall be supported. 

,5 Release 2000 all IP networks will be capable of pmviding VTN fimctionality. WN refers to both the GSM VPN 
and Intranets. The VPN features supported require further study and analysis. 

analysis. 

4.11 Security 

The general principle for security for the all IP network implementation is to reuse the same mechanisms developed for 
3GPP Release 99 wherever possible. 

Architecture for an all IP PLMN 
5.1 Reference Architecture 

The reference architecture provides two options: 

Option l: has been developed with the goal of allowing operators to deploy an all IP based irikM » Oliver Y 
Sl^tion^s/mobikservices. This architecture is based on packet technologies and IP telephony for 
simultaneous real time and non real time services. 
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Option 2:. One purpose of option 2 is also to allow support of release 99 CS domain terminals. In addition option 2 also 
supports the IP based services of option 1 . 



5.1 .1 Reference Architecture - Option 1 

As described earlier in the Requirements section 4.1, the architecture shown in Figure 5-1 has been developed with the 
goal of allowing operators to deploy an all IP based architecture to deliver 3* Generation wireless/mobile services. This 
architecture is based on packet technologies and IP telephony for simultaneous real time and non real rime services. 

The architecture shown and the components of which are described in subsequent sections allow for flexible and 
scaleable mechanisms to support global roaming and interoperability with external networks such as PLMN, 2G Legacy 
networks, PDNs and other multimedia VOIP networks. 

The end-to-end architecture consists of the following key segments: 

a) Radio Network 

b) The GPRS network 

c) The Call Control 

d) Gateways to external networks 

e) The Service architecture 

The Radio network part consists of the equipment associated with the mobile user, the Radio Airlmk and the Radio 
Access Network. The RAN supports both the UTRAN and the EDGE technologies. 

Section 4 indicates that the intent of the core network part of the all IP architecture is that it should be designed to allow 
operators to use other access networks, for example ERAN and HIPERLAN 2. Within Figure 5-1, the ERAN is shown 
explicitly, where as the other access networks are represented by the bubble labelled "Alternative Access Network". 
For the purposes of this report, 

the ERAN is defined as an evolved CSMBSS supporting EDGE modulation schemes on a 200kHz basis 
and real time packet services 

The support of alternative access networks, and the impact of the AH IP architecture on the ERAN are outside the scope 
of this activity. However, to avoid the loss of information, the report does indicated where requirements are known to 
apply to these access networks. 

Within this report, the reference point between the ERAN and the core network is designated as the Iu_ps\ That is, the 
reference point is Iu and the implementation is expected to be similar to that of the Iujps. 

Note: the use of the reference label Iu_ps' is confusing. During the standardisation activity a more suitable label 
should be chosen* 

The GPRS network part has the GSNs which provide the mobility management and the PDP context activation services 
to the mobile terminal as they do in the R99 GPRS PS domain network. The HLR functionality for the tjPRS network 
is provided by the Home Subscriber Server, (HSS). 

The Call Control part of the architecture is the most critical tunctionality. The CSCF, MGCF, R-SGW, MGW, T-SGW 
and the MRF comprise the Call Control and signalling functionality to deliver the real-time mobile/wireless services. 
The CSCF is similar to the H.323 GateKeeper or a SIP Server. The architecture has been intentionally kept generic and 
is not based on a specific call control mechanisms such as H.323 or SIP. Such a choice is for further study. 

The user profiles are maintained in the HSS. The signalling to the multimedia IP network is interface solely via the 
CSCF while the bearer is interfaced directly with the GGSN. The MRF interfaces with all bearer components for bearer 
media and with the CSCF for signaling. The MRF provides for media mixing, multiplexing, other processing and 
generation functions. 

The interconnectivity to external networks such as PLMN, other PDNs, other multimedia VOIP networks and 2G 
Legacy networks (GSM or TDMA) is supported by the GGSN, MGCF, MGW, R-SGW and T-SGW functional 
elements. Other PLMNs are interfaced for both bearer and signalling via their respective GPRS components. The CSCF 
is a new component which also participates in this signalling. The signalling to legacy mobile networks is interfaced 
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o^„, ^ t xMnnv Tcr.WnnHHSS while the bearer is interfaced to and from the legacy PSTN network 

is interfaced to and from the legacy PSTN network via an MGW. 

„ . L . . n^fwArk is currently depicted as an external entity and is described in detail in the 

the CSCF interface with the application and services bubble. 

The details for each of the functional elements of the architecture are provided in subsequent subsections of this 
document. 
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Signalling and Data Transfer Interface 



Figure 5-1: Reference Architecture for Option 1 

The Gm interface between the UE and the CSCF consists of the user to network multimedia signalling. It is 
carried on radio, Iu, Gn andGi interfaces. 

The SGSN and GGSN are the same functional elements as defined in 23.002 [4] for R99 of UMTS. 
Mobility management procedures for Release 2000 all IP network MSs ''l^^^SS^m 
2000 all lr mwwb vcv vere a mechamsm „, convert Ae format of 

old RA but Location Area Identifier also needs to be given to the 2G-MSC). Whw ™^ ™ m £ ™~ w 
2G (^th WsMity of combined update), how the 2G-MSC can retrieve the IMSI from the all IP core 
network i3 an open issue. 

MS identity (IMSI) is protected over the radio interface through ^^SSS" 
(P-TMSI) allocated by the SGSN during the MS registration procedure. P-TMSI can * >"*5™ 
following registration or routing area update, [relevance to roaming scenanos between Release 2000 all IP 
networks and legacy cellular networks] 

The Access Network Nodes (GSN(s). RNC) are not aware the multimedia signaling protocol between the UE 
I?H f t r^F ^evareTen not aware that a given UE sends or does not send signalling to the CSCF. 
Notef SoelnS p£: uoe Zuo optimize die radio, the RNC might support specific RAB for the individual 
^ws o^SrL plane. Th«e RAB am requested by the UE at POP context activation. 

Note2- the SGSN may have a role in the choice of the CSCF by the UE. This k FFS But eveni f JheSGSN 
pSS fa Mhe 5n address determination, me SGSN does not carry out the multunedia registration on 
behalf of the UE. 
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Different PDP contexts carry multimedia signalling and user flows due to different requirements on QoS for 
these PDP contexts. The Access Network Nodes (GSN(s), RNC) are nevertheless not aware whether a given 
PDP context carries multimedia signalling or not. 

Working Architectural approach 

1. The All IP Core network is engineered primarily to use a common technology (IP) to support all services 
including multimedia and voice services controlled by H.323/SIP or ISUP. 

2. Network architecture is based upon IP packet technologies for simultaneous real-time and non-real-time 
services. 

3. Network architecture is based upon an evolution of GPRS. 

4. For support of R99 CS domain services the R99 CS domain CC mechanism may be reused (NOTE: This 
does not prevent alternative mechanism such as H.323, SIP or evolved forms of R99 CS domain CC 
mechanisms being used by operators to deliver R99 CS domain services) 

5. For die support of release 00 terminals are IP based, and the integration of services is obtained through IP. 

6. Network architecture should support personal mobility and interoperability between mobile and fixed 
networks for both voice and data services. 

7. Maintain or improve quality of service levels when compared to today's networks. 

8. Maintain or improve network reliability when compared to today's networks. 

9. All IP interfaces and associated network interfaces should be enhanced to support real-time multimedia 
services. 

10. Network architecture will provide a separation of service control from call/connection control. 

11. Network architecture will replace SS7 transport with IP. 

12. Network architecture will be independent of network transport layers of Layer 1 (LI) and Layer 2 (L2). 

13. Regardless of service type, ISUP based or IP based, IP transport shall be possible for all signalling and 
data transport 

5.1 2 Reference Architecture - Option 2 

As described earlier in the Requirements section 4.1 . i item 3 and 6, the architecture shown in Figure 5-2 allows 
operators to migrate from a R'99 UMTS network into a R'OO All IP network. One purpose of option 2 is to allow 
support of release 99 CS terminals. Option 2 allows the two domains of R*99 to evolve independently. 

As for option 1 the architecture of option 2 allows that all services supported by option 2 share bearer level transport 
and bearer control. Various underlaying transport mechanisms shall be allowed (e.g. RTP/UDP/IP, AAL2/ATM or 
STM). 

Reference architecture option 2 includes the SGSN/GGSN/CSCF based services of reference architecture option 1. The 
definitions and working architectural approach described in chapter 5.1.1 therefore also applies to the 
SGSN/GGSN/CSCF pan of option 2. 

[Note: The requirement in section 4.3 for the support of routing on a single MSISDN or to allow operators to move 
subscribers from the CS services to the All IP service without changing MSISDN will be solved as part ofR99J 

Two control elements, related with R'99 CS domain architecture, are added in option 2; the MSC server and GMSC 
server. 

Option 2 benefits from the Iu architecture of R'99, having transport of user data separated from control, to allow 
UTRAN to access the core network via a MGW separated from the MSC server. Between UTRAN and MSC server the 
control part of Iu, RANAP, is used. 
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requirements that requires a network architecture accordu* to option 2 are. 



Section 

4.1.1 

4.1.1 

4.1.1 

4.4 

4.8 
chosen) 



Requirement Number 

2 (to meet the timescales of R00) 

3 

6 

all 



1 (the need for option2to meet this requirements 
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Applications 
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Signalling Interface 

Signalling and Data Transfer Interface 



| HSS») HH R-SGW*) 1 



•) those elements are duplicated for figure 
layout purpose only, they belong to the same 
logical element in the reference model 



Figure 5-2: Reference Architecture for Option 2 

between UTRAN and all IP core network. Bet 
[GW - lues (RTP, AAL2) - Iu may be based or 

MAP is operated between HSS and MSC server and GMSC server respectively. 



. r t . ^_ titraN and all IP core network. Between UTRAN and SGSN Iu is IP based. 
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5.1 .3 What is the Border of the Network 



Open Issue: What is the Border of the Network 




UE The UE can then activate a PDP context {lot me suppun ui u^i f 1 
the network that best allows to reach the MGW to be used by the call). 




[FFS]. The issue of optimal routing when an MRF is added cannot be determined 



5.2 New Functional Elements 
5.2.1 Call State Control Function (CSCF) 

In the following section, CSCF has been divided into several logical components. 

Currently, these logical components are internal to the CSCF. The need for external components to be 
address directly one of the logical components of the CSCF is for FFS. 

Every CSCF acting as a Serving CSCF (see section 9) has a CCF function. 



ICGW (Incoming call gateway) 

♦ Acts as a first entry point and performs routing ofiircoming calls, 

♦ Incoming call service triggering(e.g. call screening/call forwarding unconditional) may 
reside for optimisation purposes, 

♦ Query Address Handling (implies adnrinistrative dependency with other entities) 

♦ Communicates with HSS 



♦ Call set-up/termination and state/event management 

♦ Interact with MRF in order to support multi-party and other services 

♦ Reports call events for billing, auditing, intercept or other purpose 

♦ Receives and process application level registration 

♦ Query Address Handling (implies adinimstrative dependency) 

♦ May provide service trigger mechanisms (service xapabilities features) towards Application & 
services network (VHE/OSA) 

♦ May invoke location based services relevant to the serving network 



is the border of the network. 



CCF (Call Control Function) 
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♦ May check whether the requested outgoing communication is allowed given the current 
subscription. 



SPD (Serving Profile Database) 



♦ Interacts with HSS in the home domain to receive profile information for the ROO all-IP 
network user and may store them depending on the SLA with the home domain 

♦ Notifies the home domain of initial user's access (includes e.g. CSCF signalling transport 
address, user ID etc. needs further study) 

♦ May cache access related information (e.g. terminal IP address(es) where the user may be 
reached etc.) 

AH (Address Handling) 

♦ analysis, translation, modification if required, address portability, mapping of alias addresses 

♦ May do temporary address handling for inter-network routing. 

Other functions such as admission control, multiple session knowledge within one CSCF, multiple 
CSCFs serving one terminal for multiple services, role of multiple CSCFs serving a network etc. need 
further investigation. 

Interfaces need to be further studied and defined. 



The Home Subscriber Server (HSS) is the master database for a given user. It is responsible for keeping a master list 
of features and services (either directly or via servers) associated with a user, and for tracking of location of and means 
of access for its users. It provides user profile information, either directly or via servers. It is a superset of the Home 
Location Register (HLR) functionality., for example as defined in GSM MAP, but differs in that it needs to also 
communicate via new IP based interfaces. The HSS shall support a subscription profile which identifies for a given user 
for example: 

♦ user identities 

♦ subscribed services and profiles 

♦ service specific information 

♦ mobility management information 

♦ authorization information 



5.2.2 Home Subscriber Server (HSS) 



Like the HLR, the HSS contains or has access to the authentication centers/servers te.g. AUC, AAA). 
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Figure 5-3: Example of a Generic HSS structure and basic interfaces 
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Figure 5-4: Example of HSS structure with UMS Specific Functionality 

The HSS may consist of the following elements as shown in the Figure 3: 



1) User Mobility Server (UMS): it stores the Release 2000 all IP network Service Profile(see section 9. 1) and stores 
Service Mobility or Serving CSCF related information for the users. UMS might also generate, store and/or manage 
security data and policies (e.g. IETF features). UMS should provide logical name to transport address translation in 
order to provide answer to DNS queries. UMS role and functional decomposition are for further study. 



2) 3G HLR: A GPRS HLR enhanced to support Release 2000 all IP networks GPRS specific information. 



Gr and Gc use MAP which may be implemented using MAP transported over IP, however the issue of roaming to a 
network that supports MAP over SS7 needs to be considered The Cx interface requires further study: it may be 
implemented via IETF protocols such as DNS or via MAP procedures. 
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Following functionality may need to be supported in the HSS and are for further study: 

♦ it stores the R0O all- IP network Service Profile and stores location information for the users. 
4 it may also generate, store and/or manage security data and policies (e.g. IETF features). 

♦ may need to provide logical name to transport address translation. 

♦ The HSS interacts with the R-SGW to communicate with VLRs and other Mobility managers which do not use IP. 
HSS interfaces with CSCF via Cx which is for further study. 

♦ Other R00 all-IP based network functions such as AAA, DNS etc. and their interactions with HSS is for further 
study. 

♦ Interface(s) between UMS and 3G HLR is for further study. 

note: If the user profile is split across different databases then there should either be no duplication of information 
elements or the consistency of the data should be maintained. 

5.2.3 Transport Signalling Gateway Function (T-SWG) 

This is component in the R00 all-IP network is PSTN/PLMN terminahon point for a defined network. 
The functionality defined within T-SGW should be consistent with existing/ongoing industry 
protocols/interfaces that will satisfy the requirements. 

• Maps call related signalling from/to PSTN/PLMN on an IP bearer and sends it to/from the MGCF. 

• Needs to provide PSTN/PLMN <-> IP transport level address mapping. 

Interfaces need to be further studied and defined. 

5.2.4 Roaming Signalling Gateway Function (R-SGW) 

The role of the R-SGW described in the following bullets is related only to roaming to/from 2G/R99 CS and GPRS 
domain to/from R00 CS and GPRS domain and is not involving the multimedia/VoIP domain. 

- In order to ensure proper roaming, the R-SGW performs the signaling conversion at transport level 
(conversion: Sigtran SCTP/IP versus SS7 MTP) between the legacy SS7 based transport of signaling and 
the IP based transport of signaling. The R-SGW does not interpret the MAP / CAP messages but may have 
to interpret the underlying SCCP layer to ensure proper routing of the signaling. 

- (For the support of 2G / R99 CS terminals): The services of the R_SGW are used to ensure transport 
interworking between the SS7 and the IP transport of MAP_E and MAPJ3 signalling interfaces with a 2G 
/ R99 MSC/VLR 

For the Multimedia/VoIP domain, MAP interworking at the R-SGW is for Further Study. 



5.2.5 Composite Gateway 

Composite gateway: A logical entity composed of a single MGC and one or more MGs that may be reside on different 
machines. Together, they preserve the behaviour of a gateway as defined in H.323 and H.246<this may include SIP 
servers and MSC servers in release 2000). 

5.2.6 Media Gateway Control Function (MGCF) 

This component in the R00 all-IP network is PSTN/PLMN temunation point *for a defined network. 
The functionality defined within MGCF should be consistent with existing/ongoing industry 
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protocols/interfaces that will satisfy the requirements. 



♦ Controls the parts of the call state that pertain to connection control for media channels in a MGW. 

♦ Communicates with CSCF. 

♦ MGCF selects the CSCF depeneding on the routing number for incoming calls from legacy 
networks. 

♦ Performs protocol conversion between the Legacy (e.g. ISUP, R1/R2 etc.) and the R00 all-IP 
network call control protocols (this is still under further study within the industry). 

♦ Out of band information assumed to be received in MGCF and may be forwarded to CSCF/MGW. 
Interfaces need to be further studied and defined. 

5.2.7 Media Gateway Function {MGW) 

This component in the R00 all-IP network is PSTN/PLMN transport tennination point for a defined network. For the 
architecture option 2, the component is also used for interfacing UTRAN with the All IP core network over Iu. 

The functionality defined within MGW should be consistent with existing/ongoing industry protocols/interfaces mat 
will satisfy the requirements. 

A MGW may terminate bearer channels from a switched circuit network (i.e., DSOs) and media streams from a packet 
network (e.g., RTP streams in an IP network). Over Iu MGW may support media conversion, bearer control and 
payload processing (e.g. codec, echo canceller, conference bridge) for support of different Iu options for CS services: 
AAL2/ATM based as well as RTP/UDP/IP based. [Note: in the general R '00 architecture different core network 
transport technologies shall be possible for example: A TM, STM or IP J 

♦ Interacts with MGCF, MSC server andOMSC server for resource control 

♦ Owns and handles resources such as echo cancellers etc. 

♦ May need to have codecs. 

In band signalling impacts to MGW and R00 all-IP network is for further study. 
Functionality on the delivery of ring tone towards PSTN/ PLMN are for further study. 

The MGW will be provisioned with the necessary resources for supporting UMTS/GSM transport media. Further 
tailoring (i.e packages) of the H.248 may be required to support additional codecs and framing protocols, -etc. 

For architecture option 2, the MGW bearer control and payload processing capabilities will also need to support mobile 
specific functions such as SRNS relocation/handover and anchoring (note that these functions are provided by the 
SGSN/GGSN in architecture optionl and are not required in the MGW). It is expected mat current H.248 standard 
mechanisms can be applied to enable this. Solutions of how to use the H.248 generic bearer control mechanisms for 
mobile specific functions needs further studies. 



Interfaces need to be further studied and defined. 

5.2.8 Multimedia Resource Function (MRF) 

♦ This component performs multiparty call and multi media conferencing functions. MRF would 
have the same functions of an MCU in an H.323 network. 



♦ Responsible for bearer control (with 3G-CGSN and MGW) in -case of multi party/multi media 
conference 
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terminates the user-network 5 f ^ a °^ , 0 S the mobile subscriber's service da«a and CAMEL related da 
signalling. Tbe MSC Server also contains a VLR 1 for iwdia channels in a MGW. 

r,^ «.ll state that pertain to connection control for media channels 
MSC server controls the parts of the call state mat pe 



5 . 2 ,0Ga,ewayMSCSe™er ^^^^^^ 

The GMSC server mainly comprises the call control anu 

5.3 Description of Reference Points 

5.3.1 Cx Reference Point <HSS - CSCF) 

the transfer of data between the HSS and the CSCF. 
This reference point supports the transfer , _^HSS This will allow the HSS to 

determine which CSCF to direct incoming calls to. un tn 
(application related) to CSCF. 

For a MT call, CSCF asks the HSS for call routing information. 

5.3.2 Gm Reference Point (CSCF - UE) 

This interface is to allow UE to conumuticate with theCSCFe.g. 

• register with a CSCF, 

• Call origination and termination 
. Supplementary services control. 



5 3 43 Me reference point (MGCF - MGW) 

th MGCF and MGW between the MbC 
The Mc reference point describes .the '^^^^ ft has the foUowing properties: 
Server and MGW, and between the<3MSC Server ana mu 

. foU comphaiu» with the H 24»sian^, G 
T Study t3roup 16, in conjunction with IETF MfcUAv. 
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0Ut a «hv«ral MGW can be partitioned into 

. «„Hon2 the functionality across the Mc reference PO^^J^Megaco standard mechai^im 

can be applied to enaoic uu». 
functions needs further studies. 

534 Mh Reference Point (HSS-R-SGW) 

R99/legacy mobile networks. Tins is requireo 

5 3.5 Mm reference Point (CSCF- Multimedia 

SmanotherVolP call control server or tennmal. 

5.3.6 Mr Reference Point (CSCF - MRF) 

AllowstheCSCFtocontroltheresourceswitotheMRF 

5.3.7 Ms reference Point (CSCF - R-SGW) 

5.3.8 Mw ReferenoePoint(CSCF-CSCF) 

5.3.9 NcReferencoPoin.sCMSCSer.r.GMSC^ ^^^ 

based signalling transport (Note, m the genera 
shall be possible.] 

5.3.10 Nb Reference points (MGW-MGW) ^ 

ni „t the bearer control and transport are performed. ™j™™Pr_p h 2 45 or corresponding. 
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5.3.1 1 SGSN to Applications and Services 



support Charging Application Interworking. 

5 4 Usage of MAP/CAP - Protocol stack below MAP / CAP - 
General considerations 

Below MAP and CAP, the protocol stack within the All IP CN is as shown in Figure 5-5: 

services of SCCP is for further study, 
telecommunication signalling on top of an IP backbone. 



MAP/CAP 



TCAP 



SCCP 



Adaptation layer 



SCTP 



UDP 



IP 



Figure 5-5: All IP R00 protocol stack for MAP/CAP 



This protocol stack is used to carry MAP/CAP flows: 



s protocol stacK is usea«j«m;ri«™< — 

^ MAP/CAP- ee between HSS or SCP and the All IP CN 
inside the All IP CN, between »<« ™^ tfMPM* with the HSS or SCP for user 

functions (SGSN, MSC serve*-.) ^^<* U ^ "£ «£b *e case of the Gr. Gc interfaces. 

subscriber data retrieval. 

. v m AP/r ap over IP stack (e.g. 2G or UMTS R99 networks 
in case overworking with nodes not supporting tins W«uu _o e stack. This protocol stack is 

IToS but need.ng a MAP / CAPdW* «£j use MAP over * for ihe 

used between the ^ es ™^ Q ^^ nd GPRS (excluding the VoIP/Multimedia domatn). hence tins 
roaming scenarios involving the R00 CS domam a of MAP on the Ms is FFS. 
does not exclude other protocols being used. The use ot mat on 



QoS 

recurrently bemgdon*^ 

TR 22.105. The R99 version of diese specifications ^"* u PP° rt r ^ Rations ,nat utilize the H.323 protocol 
which includes the ability of UMTS ^^^^^^^lononcM^f^^^ 
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support QoS capabilities necessary for support of multi-media based on H.323 or SIP within the PLMN. Doing this is 
not expected to introduce any new QoS requirements at the UMTS bearer level. 

In additon, please note that the desire also exists to have the all-IP architecture ^support multi-media applications that 
utilize the SIP protocol However, QoS work related to the SIP protocol would only be undertaken within 3GPP when 
££? tSSSm ! the work to support the SIP protocol. However, we do anticipate that the QoS work centered on 
H.323 is directly applicable to SIP. 

In addition, since the work on die all IP network includes EDGE support "identified by the ERAN architecture, the 
QoS work within the ERAN needs to be in alignment with QoS support within UMTS. 

A preliminary review of the current version of TR 23.907 leads us to believe that it is largely sufficient to meet the 
objectives an all IP network. The review includes the following observations : 

- TR 23.907 includes the specification of a QoS conversational class which includes voice. TR 23.907 identifies 
the fundamental characteristics of mis class as: 

- Preserve time relation (variation) between information entities of the stream 

- Conversational pattern (stringent and low delay) 

- These characteristics apply whether voice is carried within a circuit or as packets. So there should be no need to 
modify the QoS classes currently defined. 

- Implementing the H.323 call model within the PLMN is not expected to affect *e R99 TR, ^dentified 
QoS technical requirements, the overall architecture, nor the functions identified therein. However, a brief study 
will be necessary to verify this. 

- The Radio Access Bearer Service attributes currently defined will need to be reviewed in light of an all IP 
newoTk but minimal additions in this area would be expected for UMTS. However, for EDGE, work should be 
anticipated. Obviously the mapping from bearer to radio bearer is also affected. 

- The issue of interworking the packet voice capable GPRS with other networks needs to be studied at least as it 
pertains to an acceptable voice delay budget 



7 Handover 

Within this section, the topics to be studied and standardised to support handover for red time services in the PS domain 
^"identified. This section has investigated various handover scenarios, however the fact tiat the ^scenario has 
been studied here does NOT imply a requirement for the support of that scenario. The requirements for handover 
SinT To S IP^chfeeZ of R00 in UMTS will be determined by S 1 as part of the R00 Service Requirement 
specification work. 

7.1 SRNC Relocation within a UMTS R00 IP network 

Within UMTS, work has already been undertaken to provide handover for real time PS domain ™e^The UTRAN 
does not distinguish between circuit and packet services, it simply provides for real and non-real time services, hence 
Intra RAN handover for real time services is available. 

7.1 .1 Support Required within ERAN 

The R oal of the All IP architecture is to provide a common core network for both UTRAN and ERAN. The specification 
oS work is outside the scope of this study, however, it is worth noting that the ERAN will need to support the 
following procedures: 

• SRNC Relocation 



Mobile Assisted Network Controlled handover for the real time packet services. 
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7.1.2 All IP UTRAN to All IP ERAN Handover 

7.2 SRNC Relocation/Handover Between All IP and CS 
Domain/GSM 

7.2.1 Requirement 

The need to support these handover scenarios is for FFS. 

^ expected scenarios: support the necessary RT requirements for its packet 

. Inter system handover, where *r B et ^ ^ **** 
domain (c r. Inter system hand-over towards W O 

To fulfill this potential requirement, 2 solunons na 



would face tie following issues: As the MS after the HO is handled by 

, The MS has one or more PDP «^ * ^<^.^ ±e m ^ ta traffic is now 

attffl^-^~ -te-fc- ^ f ring 
, Mult^CCn^sagess^^^ 

the Multi-media protocol messages on top of GSMCSsignan g 

the MAPE interface needs to be investigated. 
3. HowdoestheSGSNdetenruretot^ 

7 2 2 Solution with CSCF supporting MAP E 

•„ scenario when a UE has at least one session active which involves the CSCF. 
ThefollowingtextconstdersthescenanowheBaUt cowp relocation results in a change 

OnrecerptofanSKKCreloc^ 
ofSGSN^onewluc^^^ 

SpTJsS^ ^^Wed sessions to a 3G-MSC. 

CoCr to UK ovj»ji^ «***»* it chows that the use of the 

CSCF which acts at the "Anchor MSC . However, ^ 
within the network. 

! . On receipt of "SRNC relocation Required Message" SGSN checks for 
• Do any sessions involve the CSCF? If so, 

» i« the taraet SGSN an EXiSN? . 
' 15 mg Xiicr . ^te. i c sends "Forward SRNC Relocation" 

2 . S GSNsigr»us«otheC3CF«r»tah^^ 

meSSagC t. mop includine the information received from die 

3. CSCF signals "Prepare SRNC Relocation" to Non-anchor MSC mcludurg the 

Source RNC 
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4. Non-anchor MSC starts the Relocation process, treating the CSCF as the Anchor MSC. This allows the Multi- 
media client CC messages to be tunneled through the Non-anchor MSC to the CSCF. 

5. The CSCF instructs the GW to prepare to transfer the traffic between the PSTN and the Non- Anchor MSC. I.e. 
to take the GGSN out of the path. 

6. Successful switch of the bearers at the RNC, takes the SGSN and GGSN out of the path. The GTP tunnels are 
then released. 

Open Issues: 

1 . How does the SGSN determine which sessions involve the CSCF? 

2. How does the SGSN inform the CSCF to request a connection from the MSC via a MAP-E interface? In the case 

of the CSCF being in an external network, it may not be possible for the SGSN to know the CSCF address. 

3. For a Mobile to PSTN call, the CSCF will need to signal to the GW to route PSTN traffic to the 3G-MSC 



7.2.3 Inter-System handover using the ISHF 

The mechanism described in this section, identifies a new functional element, the ISHF. This isolates MAP/E from the 
CSCF. Further work is required to identify if this approach, or the approach of supporting MAP/E on the CSCF (see 
section 7.2.2) should be adopted. 

7.2.3.1 General 

Based on the handover requirements given in Table 4-1, the following intersystem handover scenarios should be 
accommodated by the All IP architecture. 

• UMTS R 00 IP network to/from 2G GSM network handover 

These procedures listed shall not require change to the tenninal. 




Signalling Interface 

Signalling and Data Transfer Interface 



Figure 7-1 : Support of InterSystem Handover 

To support intersystem handover it is proposed that a new function is added to the architecture, called the InterSystem 
Handover Function (ISHF), see Figure 7-1. 
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The changes/additions to die baseline architecture given in Figure 7-1 ""l"* 1 ^^ R 00 IP networks and UMTS (PS, 



2. 
3. 
4. 



Signaling pivww— 

source and target networks. ff 
„a iste *H.co^en 1 S W ^d«^W.^^« 1S MAPm^iau,.d MS ,« Ml o M d rf r 

messaging between networks. , 

^ J u rrw Thk interface relays handover related Iu signaling between 

l, [ ,.»alBniei«t«o* S fo.ii«er^st««li.ndo«er. 
K.aaaorn^d^Wo^.^*^^^ 

7,3 2 UMT SR00IPnetvminWfrom2GneW«»1 ( hando«r 

jc, ttmt^ R 00 IP network to a legacy GSM 
This example shows how handover (Hard ^^^^"n^^ a mink circuh bearer between the 
TO. demonstrates the signaling required between ^ ffl ^ exflinple . (Note that all the a* 

networks. Other bearer connection « £ addition, the MGCF and T-SGW are shown as a 
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Figure 7-3: UMTS R 00 IP to GSM handover (continued) 



UMTS R 00 IP => GSM handover ,. f . ^ 

! u,ISBF«lll»«ltl«MAf/EPrq»™H«»l.»"t«>I.R.SOW. 

MAP) and sends the message to the other network (MSC) 
Note- Steos 4&5 Mow the normal GSM procedures and are shown only for clarity. 

Note. Steps 4&5foUo msC/BSS the MSC returns MAP message Prepare Handover 

6. Once initial procedures are complete in GSM MSC/BSS the mk, 

ResDonse to the R-SGW. ^ 

„ A to me MAP/E protocol and sends the resulting Prepare Handover Response 

7. The R-SGW converts (if required) to the MArVfc protocol « 

message to the ISHF. ln to case a trunk circuit is 

/MnrF T SGW shown combined for simplicity) to establish 

9. TheCSCFsendsaCOWECT**ec«u rt ^ 
an outgoing call to the MSC. 

10 . The circuit gateway sends the ISUP IAM message to the MSC. 

11. The MSC responds with the ACM message. .^crnc 
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Parameters: Handover type. 
Note: Procedures related «o synchronization etc. to GSM BSS are not shown. 

17 . D etl of *e UE - GSM covemge — ^ - « — ^ ~ ^ 

Request to the UMTS R 00 IP network (R-SGW) 

18 The R-SGW forwards the Send End Signal Request to the 1SHF. 

19 . lS HFiniuatesre.easeo«^ 

20. ISUP Answer is sent from the MSC to the Circuit Gateway. 

21. Connect is returned to the CSCF function 

22. ConneetisrelayedbacktodtelSHF. ^ ALCAP protocols 
23 Previously allocated bearer resources are released wrthm UMTS (e.g. us g 

rALCAP not shown]) (Iu Release Complete). 

24. Procedure is concluded from UM l & pom. ■ 
(this message is not sent until the end of the call). 

25. The R-SGW will send the MAP Send End Signal Response to the MSC. 



7.3 Areas for Further Study 

The following areas may require further study. 

Bearer set-up/control between networks during handover 
Anchoring bearer in the UMTS R00 IP network 
MAHO support 
Inter-RNC Soft handover 
Inter RAN to RAN of same type streamlining 
Inter RAN to RAN of different type streamlining 



8 Radio Aspects 

Note: This section requires support from the RAN group. 

8.1 General 

n CN - RAN interface definition foprs Radio 

(.) Funcdor.lsplitbetwee^^ 

AccessNetwork^NJiscrmsidered ^««J«J^^ ^ d|Wlir 

as ERAN or UTRAN and the CN needsto ^^^J ljt cn „, 

interface technologies to access to the CN. lneoeraucaiun 

RAN needs further investigation. 
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network) r^ntrnl and user planes from CN to both 

(d ) Protocol stack evaluation (including evaluate of control and user p 

RAN and MS) 

2) ERAN architecture (Refer to SMG2) functional elements 

(a) ERANreferencemodel-networkentities,protocolstacksandlo g ,caio 

(b) Functional split between elements 

strategics 

3) UTRAN architecture extensions 
(a) Identification of required extensions 

4) Realtime Handover for Packet Domain 

(a) ERAN issues (Refer to SMG2) 

(b) UTRAN issues 

(b) Signalling mechanism 

(c) CN issues 

(d) Alignment of GPRS with UMTS QoS 

(e) Realization of QoS on radio link 

6) (E)GPRS Radio issues (Refer to SMG2) 
(a) Real-tirncsupr*^ , '. , 

% Spectrnm eXncy/performance (e.g. statistical multaplexmg and 

source/channel coding) 

(c) RLC/MAC enhancements .^tnnn availability) and traffic mix, such as 
' ^ effect of various deployment scenarios (e.g. spectrum avaHawuty; 

(d) ^cetd l^nspecman .efficiency should be cons.dered. 

7) UTRA Radio issues validation and possible 

(a) Real-topacketdatasupportincludmghandoverandQoS vahoa 

(b) RtreTclcy/performance (e.g. statistical multiplexing and 
source/channel coding) 



as voice and data, on spectrum — ■> 

M,,e: The RLC/MAC hue items about (sections 6(c) and 7(c)) may include 
• Enhanced for radio resource allocation. ,„„.,>« nuth 

. Flow classification (e.g. mapping of user traffic onto app y A ^ manaAaastA 
. EnlunxementofEGPRSpro^ 

(e.g. Fast channel allocation schemes). — — - 
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8.2 



Airlink Optimisation for Real-Time IP 



w ,cally shorter than me ir 0T cven get close to the baseline spectral jp^p/Rfp hea ders to 

^ ^ T£2bS«£ SkSd*. onto » the WW* 

and IP transparency. 

ft 9 9 user olane adaptation 

^ssssssssasssssssss 

8.2.2.1 Full opacity (no adaptation) ^^^fom.tionisdonconthe 

T* UPA has no knowledge of the internal of ^^^^ ^^10^^^ 

S^DPAOT headers which « sent in fall over Ae air •"^^SKSfe sponger error protection than fce 
S Evenly to aU the bia in the no JT onceahnent 

Lload, sine* a header k»s wfll requ.re to Jscwd Ae^ 

efficiency. 

8 22 2 Payload opacity (header adaptation only) 

82 221 Header compression/decompression ^ ^ 

,P,UDP/RTPhead^ 

S headers require stronger error protection ^yloa^mwt In general compressed 
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and downlink respectively. 

requirement is also provided. — — 



Focus Area 



Performance / 
Spectral 

Efficiency 

IPv6 or IPv4 



Requirement 




Must provide low relative overhead ps aefined 
in [1]) under expected operating conditions 



Must include support for IPv6 anO irv* 



Ubiquity 



Cellular HO 



Integrity 



Error Propagation 



Delay 



Packet Loss 



Must NOT require modifications to exisung IP 
(v4 or v6), UDP, or RTP protocol stack 
implementations 



Justification 



Ipv4 and Ipv6 terminals are expected to coexist for 
sometime 



Enables use of current devices/services wn.cn employ 
generic IP/UDP/RTP stacks. 



Must support the cellular handoff operation, in 
an efficient manner. All fields must be 
transparent to the HO process, i.e. are exactly 
regenerated subsequent to handofl. 

The header compression process must be 
lossless 



Target application is for adaptation ot the user plane on 
cellular air interfaces; therefore this operation must be 
supported. Efficiency requirement is due » potential 
i„J!ac«s on spectral efficiency and voice quality if HO 
is not properly handled. 



Would like to maintain the end-to-ena integrity of IP 



Error propagation due to header compresion 
should be kept to a absolute minimum or 
avoided if at all possible.; error propagation is 
defined as the loss of packets subsequent to the 
one where the error actually occurred, even when 
those subsequent packets contain no errors 

Must operate under all expected delay 
conditions; header compression process must not 
contribute significantly to system delay budget 

" Must operate under all expected pacxei .os* 
conditions; prefer that header compression 
efficiency is as independent of packet loss re 
possible 



Error propagation results in lower spectra, etfidency 
and lower voice quality, this is a senous problem for 
existing schemes such as JS]. 



The user may be in different types of environments 
with different characteristics; additional delays wtll 
have adverse effects on conversational voice 

H* user may be in different types of environments 
with different characteristics 
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Media 
Supported 



Independence with 
respect to call type 



M^nu^ionregardlessoimeJiatypeinRTP 
payload (in general, there is NO reqmred 
knowledge of payload) 

Must function for mobile-moh.ie ana moo.«=- 
Lline calls; perfonnance in c* : ce* *o u.d 
be comparable to existing cellular (m terns of 
both quality and spectral efficiency) 
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Tile algorithm should be *^»f**» * 
RTT/UDP/IP data flow, note that this does not 
p3 optional o ptimizations for cena.nmed.a types 

B^^ofcallswilloceunnAll-ircellular " 
systems; each is equally important 



Table 8-1: Requirements for Header Compression 



IP 




IP 







IP 



imp I RTP I Voice sai 



. p» | UDP| RTPl VQlces^^ 



Header compressor 



(UPA point) 

X 



L2A.1 
(IrdertMvlnB, 
channel coding, eta) 



Compressed header 
y | | Voice I 



Header decompresso 
(UPA point) 



Air interface 



un.1 

(detnterteavlnQ, 
ihannei decoding, etc 



Figure 8-1 : Header compression 
ft 9 222 Header stripping/regeneration 

o./>. Generated at the receiving end* 

IP/1 IDP/RTP headers are stripped before transmission over ^.^^^/^^tion needs to be transmitted to 

respectively. 
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IP 



- Innpl RTPlvCce^je] Qp | »DP | RTF |Vo.cj^ 

i 1 



Header compressor 
(UPA point) 



L2A.1 



chaw* coding, 



Informtium 
to support 



regeneration 



IBS 



Air interface 




Figure 8-2: Header stripping 

8 2 2 3 No opacity (fall adaptation) 

the payload structure, etc. 

8 2 3 Application to all-IP network 

ThealMP network is expected to provide reaUtixnebc^se^ 



• Basic ci 



optional voice (service equivalent to voice in current cellular) 



as 



a component of multimedia) 



• Real-time Multimedia tincludes voice which is seen 
c 2 3 1 Basic voice - 
I p «^eSnt^ 

Sown techniques such as unequal b«t P« J- imbSln the al.-ff system, we proper to define a basic 

^ic voice will use pavload opt^^ 
Sgmorespee^ 

which negatively impacts voice quality. Transmission ot neao 
require strong error protection. 



Two options eexist to achieve required characteristics for Basic Voice: 



Two options eexisi ro awiiicYciw H »aaw^ 

M 2£"* Jo die full adaptation case above with header stripping. 
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A - * ra r^rutics- By osina a robust header compression scheme the overhead 
compression. 

8 2 3 2 Real-Time multimedia 

to the criteria of table 8-1 of chapter 8.1.2.1. 
8 2 3 3 Pure IP 

criteria of table 8-1 of chapter 8.1.2.1. 

8 24 Conclusions 

inuM»«d»(RTMWBVb^«»fc^»^ 

. RTMM -- .1— h *"^ t *»— ^ 
bit protection in the payload shall be invesngated. 

. F^^cewHlsuppondata^ 

possible for Pu« IP. Pure IP uses equal bit protection in the payload. 

In all cases, header (if present) requires strong error protection. 



Call Control 



9.1 Terminology for Call Control 

■ 4 . # i_ nMW or has been chanced from that defined for 
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should be used unless a new or changed concept is introduced. Changes to terminology defined by SI require SI 
agreement 

This section defines a common set of terms on which the present document is based on. The following list of terms is the 
first attempt to define some terminology. 

The terminology defined here have not been matched with the existing 3GPP terminology and this matching will need to 
be done. Moreover, 3GPP has not defined all the terms that are needed for an all IP based network yet 

1 Access Profile: contains subscription profile information relevant to a specific bearer network. As an example, E- 
GPRS profile plus the radio bearer features (e.g. QoS) to which the user can access is an Access Profile. Access 
specific roaming information for access to and from legacy networks is a part of the access profile . As an example 
for CS terminals, Access Profile contains information on the allowed LA, on security data for authentication 

2 Release 2000 all IP networks Service ProfiBe: contains service subscription data relevant to the Release 2000 all 
IP network services the user has subscribed to. As an example, Service Profile contains user's identifier, user's 
aliases, user's temporary location information (e.g. pointer to the current Serving Domain), indication of the 
multimedia services and capabilities the user has subscribed to, service triggers, status of supplementary services, 
etc. 

3 User Profile: is a combination of one or more Access Profiles and zero, one or more Release 2000 all IP networks 
and Roaming Service Profiles. The User Profile is maintained in the HSS. (FFS) 

4 PDP Flow: it is a PDP context without the restriction that a different IP address has to be assigned to different PDP 
contexts. Differentiation between PDP flows is based on protocol type (e.g. TCP, UDP etc.) and port number. (FFS) 

5 Bearer Network: it is a set of network elements that provides a user with means to connect to a serving/home 
domain to use services or facilities of the network the user is roaming in and gain access to the home domain or 
other service networks. Examples of bearer networks are: 

o E-GPRS plus one or more different RANs; 

o Cable Access Network, etc. 

6. Domain: A domain is a logical association of network elements. A domain may contain any number of HSS, 

CSCFs and MRF. A domain can be Home Domain for some users (those whose subscription profile is stored in the 
HSS in that specific domain) and Serving Domain for other users (those whose subscription profile is stored in the 
HSS in a distinct domain). A domain can connect to a multitude of bearer networks. (FFS) The purpose of 
introducing the domain concept in release 00 is to enforce access Independence in the core, support of NAI 
addresses, scalability, additional services and servers expected (ex. Email/CSCF interworking), allow the use of 
DNS and directories for translations. Domain's already provide the glue for many useful services and 
functionalities. A domain is a logical realm that indicates a system or zone. A domain is used to associate services 
and servers with a common identifier for translation purposes. A domain is used as a key into databases in order to 
obtain the network addresses of nodes for respective services associated with the domain. The actual location of 
nodes supporting these services is not restricted in any way by a domain. The term domain used here refers to the 
DNS definition of domain. 

Open Issue: The use of the term, domain, home domain and serving domain requires further clarification and analysis. 

7 Home Domain: it is a domain that contains an HSS. In particular, the Home Domain of a user is the domain 

containing the HSS that stores the user profile. Home Domain may or may not contain the Home CSCF, the MRF or 
service logic. Home Domain: 

o provides and maintains the user and user's subscription data in a HSS for the user belonging to the domain; 

o supports also access independent users and users profile such as browser bookmarks and phone lists; 

o user provides and updates the currently visited serving domain with user's profile; 

o store routing and mobility information that enables service delivery to users and users roaming outside and 
inside the home network; 

o maintains roaming agreements and service level agreements with other networks; 
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CSCF; 

. nay collect and consolidate charging data. 

Other functions are FFS. 
g Serving Domain: 

. rr.rr-rr- — 

. optionally collects data for billing and statistics; 

. , ri „„b aS edservicesandinforn«non(e.g.advert 1 ser n ents,operator 

. can provide local services such as locanon based services 

announcomentstolocalevents.etc.); ^ 
. pxovides optional resources such as conference devices, n^nmedia 

providedinhomenetwork) »he user is registered in the home domain. (FFS) 

. Home Domain can act as Serving Domain when the user is registered 

• One ot more domain(s); 

. Any number of bearer networks); 

. ConnectivitytooneormoreMGCFsandMGWs. 

Zero one or more MSC/GMSC Servers 

of that specific user. (FFS) 
,2 Service Logic Domain: includes the following functions: 
. contains existmgte^ 

nntains WAP type capabilities for Web-based services; 

. — -- * 

Service Logic Domain operator; 
.. providesaccesstoorcapabilitiestoreachomerSe^UgicDomain; 

.omelocationbasedservices^nalsoresidemtbeServiceUgicDoma^ 

• some location pas „„ m( . Network in order to manage/charge/provide 

Th. Servico Ugic Dormm could have a nght coupling wim the^H^ 
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coordinated/transparent fashion. The Service ^SS'^SdS SlJSce logic 



domain. 



user \ 
home domain. 



14 Roaming User: is a user roaming outside its Home 



Network and being served ma Serving Network. (FFS) 




Figure 9-1 : Modelling of the network in domains 

15 Legacy Network: a legacy network can be: 

. SS7 based networks (e.g. PLMN, PSTN and ISDN) as well as CAS based networks; 
• GPRS networks. (FFS) 

- ^^^^^^^^^ 

with Release 2000 all IP networks. (FFS) 



translation of the aliases. (FFS) 



9.2 Assumptions 



The following assumptions have been 
version of the document. 



considered in the development of the roaming models described in the present 
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1 The addressing requirements and mechanisms will be based on the requirements and mechanisms identified by 
3GPP in 3G TR 22.975 and 3G TS 33.003. 

2 Call admission/denying and call re-routing will be considered. Details of call admission (e.g. authentication and 
QoS) will not be discussed here. 

3 Re-routing of incoming voice or data communication requests that are addressed to the user's directory number 
during periods of realignment of the national numbering plans will be considered. Probably, a non final solution 
(e.g. re-direction of calls based on databases) will be provided. 

4 A specific PDP flow (called Signalling PDP flow), distinct from PDP flows carrying media PDUs, is adopted to 
cany signalling between UE and CSCF (e.g. call set-up, in-call signalling such as flash requests). The signalling 
PDP flow does not need to have an IP address different from the one of the PDP flows carrying the media. 

5 The user profiles are stored in a permanent way into a database/server in the Home Domain. 

6 In case of roaming the user profile in the home network must be interrogated by the serving network at least at 
registration and part of user profile could be temporarily stored into the serving network. 

7 The roaming architecture will be optimised with the assumption that IP addresses will be allocated dynamically. 

8 No new requirements would be placed on the legacy (e.g. PSTN, 2G PLMN) and Multimedia IP Networks to 
interconnect with the Release 2000 all IP networks. Release 2000 all IP networks would have to ensure inter- 
operability with the existing legacy and Multimedia IP Networks. In case a 2G HLR (e.g. GPRS HLR) is re-used to 
hold data for Release 2000 all IP network users, the 2G HLR will be upgraded to support Release 2000 all IP 
network user and its interfaces might need to be upgraded. 

10. An MS registration procedure consists logically of a bearer level registration (e.g. GPRS attach) and, if so 
specified/allowed by the MS subscription profile, an application level registration. MS registration is performed, as 
an example, at MS power up. 

1 1. The bearer level registration procedure entails registration with the GPRS nodes, according to GPRS-derived 
procedures. 

12. The application level registration procedure entails registration with a serving CSCF/MSC server in order to inform 
the CSCF/MSC server of the MS presence and to allow the CSCF/MSC server to retrieve the user information from 
theHSS. 

13. Bearer level registration and application level registration are considered to be two separate procedures. Bearer 
level registration completeion may trigger in the UE a signalling PDP flow activation as a possible mean of 
supporting the application level registration procedure. 

14. The MS location is tracked at the GPRS level using GPRS mobility management, and user mobility is tracked at 
the application level through a specific procedure aimed at updating the user information maintained by the CSCF / 
MSC Server and, possibly, location information held by the HSS." 

15. HSS keeps track of the user mobility in terms of the current CSCF/MSC server or Serving Domain. 

16. Support of multiparty voice and data communication sessions (including the capability for the user or service logic 
to dynamically add or delete users from an active communication session) is not considered in the present version of 
this document 

17. Roaming agreements (static or dynamic) between the co-operating operators must exist. 

18. Service Level Agreements (SLA) between network operators are defined (statically or dynamically) to ensure 
consistent level of services (e.g. end-to-end QoS, security etc.). 

19. All network components that require address analysis and address translation for routing of terminating calls (e.g. 
CSCF, MSC server, MGCF) are capable of doing so or has access to consistent translation databases or to the HSS 
in order to resolve routing/call termination issues. 

20. O&M functions exist to connect various components of a Release 2000 all IP network to each other, making it 
possible for each component to know how to address/access any other component within the network domain. 
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21. O&MfunctionsexisttomakenetworkprovB.onmBPtofilesCe-B-* 

domain whenever. GGSN will be preferably located in the serving network. 

22. in order to obtain user-plane optimisation, the serving GGSN will be pr 

x a ^i^triecers are either maintained by the HSS and/or 

23 Service profile (subscription and activation status) and service triggers 
up7a£ by the HSS towards the CSCF/MSC Server. 

24 C8CF^cdl•^F^^i■^ to,e ^. ,Wk:,, • fc rscF For 
2,^08*^0^0*^ 

serving CSCF is controlling the current call). . . 

r* & Home CSCF is are needed in aU the roaming scenanos in order to support. 
26 Some of the functions of the A Home CSU- is are ncca 

nv. ftftm nmerRelease2000aUIPnetworksorMulnmed.aIPNetworksw,th 
. mcoiiung calls addressed to a DNtrom other Relea^/wu 

itS routing (i.e. calls not routed through PSTN). 

(LogicalName); „ ScreeninK-like functions for terminated calk (e.g. 

. implementation of supplementary services and Incoming Call Screening Idee run 
Call Forwarding Unconditional). 

9.3 Roaming Within All IP networks 

In me follow, a set of roaming scenarios is described. * A tn k 7 mav not 

yi and the names shown in the diagrams from 6.4 to 6.7 may not 

Edjtor^tioteipleasenote that the network Interfaces and the names 

always be correct. 

9 3 1 Call Model 

d ' a ' Release 2000 all IP networks originated with a DN can be 

. Calls from a Release 2000 all IP network to a *^™2£mcM00 ^ „, Mtworks has knowledge of the 
optimised (i.e. no. routed to PSTN) only ^S. route the call directly to the destination 

nLibering plan of the ^Z^J^Vi^^ optimisations could be possible if the network 
Release 2000 all IP networks without leaving die ~Lg ^Jjjj network to which the call is destined and 

:r;tdtg^ 

network originated with a DN. (FFS) 



Serving CSCF direcdy. 

• i. ^ Kv the Serving CSCF/MSc server (when present), or the 
Regarding originating calls, the call request is handled by the serving ^ 
Home CSCF when a Serving CSCF is not present 
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This section covers only PS seivices. 

9.3.2 Scenario 1 , Traditional Model 

Tte following pictures show respectively the roaming scenario 1 
to roaming between networks. 



applied to roaming 



inside a single network and applied 




Figure 9-2: Scenario 



1 applied to roaming inside a single network 




Home 
Network 



Figure 9-3: Scenario 1 applied to roaming between networks 

The following points characterise scenario 1 : 
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both a Home CSCF and Seeing CSCF a« Fescn. and active; 

« , §Um c prv ino CSCF through the Home CSCF; 
MT calls are routed to the Serving CS t % invoked by MO calls and requiring interaction with service 

r»n-basic services^ 

logic specific to the home network operators P interface to a SCP in case of IN), case (1) in the 

ServingCSCFhasadirect interface to theservic* logrc (e.g. duect mterface to a 

depictures; ^^tot-cn*^*******-**" 
only Home CSCF has access to the service logic arm 

^^abovepicntre, ^^OCF for basic voice senses; 

MT Calls which reach the Serving CSCF are nanoieo y 



• ^^^^^^^^ 

inteirogatioa 

Q.3.3 Scenario 2 2 applied to roarning inside a single network and applied 

The following pictures show respectively the roarmng scenario 2 applied 
to roaming between networks. 




Figure 9-4: Scenario 2 appUed to roaming Inside a stng.e network 
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Home 
Network 



Figure 9* Scenario 2 applied to roaming between networks 

The following points characterise scenario 2: 
• only a Serving CSCF is present; 

. MT calls are routed to the Serving CSCF through the ICGW in the Home Domain/Network; 

. all the services (basic and non-basic) invoked during MT and MO calls are provided by Serving CSCF; 

. ,f -non basic" service means non standardised, these services will involve serving CSCF and elects within the 

Home domain and service logic domain.] 
. userplaneforMTcalbisroutedfromtheoriginanngnetworktotte 

(i e from PSTN to MGW to GGSN in the serving network); 

chosen "close" to the bearer network again in order to optimise toe rounng 01 P 

9 3.4 Scenario 1 : Information Flows for Validation 

,„ order to validate scenario 1 proposed above, information flows for registration, location management and call 
delivery/origination are provided in this section. 
rneinformationflow^presentedintheCaU Control 

have been chosen for signalling messages. Any S possible information flow, is 

proposing information flows immediately comprehensible. Only a restneteosuw. 

included in the document. 

9.3.4.1 Registration and Location Management 

. I„ this version of the Technical Report, only a basic registration procedure is considered. 
. The basic registration procedure is composed of three steps: 
• GPRS attach: is a plain GPRS attach procedure; 
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. PDF context activation: a PDF context is set up to support application level signalling; 
• application level registration with CSCF. 

The latter is considered in the registration flows reported in the follow. 

Two basic cases of registration are shown here, i 
registration. 



, in order to provide an initial picture of the application level 




t^orinn in Release 2000 all IP network Serving 
Figure 9-6: Release 2000 all IP network "~£*J£ nn ' " Re ' MSe 

Steps 4 and 5 are optional and take place only in two cases: 

. if the user was previously registered in a different Serving CSCF; 

. iftfcuserwasnotp-o^^ 

needed in the Home CSCF to handle the supplementary services tnggerea oy 

forwarded-to multimedia call triggered by the MTcall). 
Other registration and location management scenarios are FFS. 

9 34 2 MT/MO Calls 

Mowing call delivery model: 

Network, ISP or corporate LAN domain in the IP multimedia network, 



• MGCF reaches the Home CSCF translating the DN; 

reform 

can has to be routed: in the flows ^w. her^ H^^^e 



. „ oTO CSCF interrogates the HSS^^ 
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Aic uccmii^t return service profile information in case the user is 
Serving CSCF or a forwarde-to number). Also, H5>5> rrogm rem™ « v 
not registred. 

. Home CSCF forwards call signalling to the retrieved address 

Regardinguser-plane, packets ^^^W***^™^^-***"™* 
the bearer network where the user is presently located. 



in 



Li 10 ™«. th« ell »»™Js PSTN cm be choce u>i»8 P"**" 

9 34 21 Incoming call from PSTN to a Release 2000 an IP network 
*'^i-^ fc «*^*'»-^" , "»' ,M --"" ,ir " - "" ,< * ,,,,d 

through a DN. 

L | MGW .j | MGCF |^ PSTN | 



xRAN 
T 




SGSN 



ggsnJ^ 



MRF 



GPRS Attach, Signaling POP Flow Activation, CSCF 



Notify! user of 
Con inuc caD 




PDUFimk 



bicomin ; 



Query ^ 



Locitio > 



S1PVEJ 



Ringing 



Answering 



SERVING 



IPPDU 



Circuit 



IA 



Ringback 



HOME 



Figure 9-7: Incoming call from PSTN to a Release 2000 all IP network 

Issues such as QoS negotiation, policy management, etc. arc FFS. 

9 34 2 2 Call from an 3GPP IP based network/Multimedia IP Network to 3GPP IP network 
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- from, is aware of the addressing plan infonmtion 



assumed that the Release 2000 all IP nc j^ r j.^* r * t^lmSnate intoAe H^SCT (otherwise, it may have been routed 
(IP based addw>.-.», . !rrn 

through the PSTN and terminated into MGCF). 



-ough the PSTN and terminated iT" " 
Details will need to be worked on. 



TERMINATING «T. 




POUFi «ne(v<**) 



rPPOUfvotoe) 



POU Frame < 



Figure 9-8: Call from Release 2000 all 



IP network to Release 2000 all IP network 



9.3.5 Scenario 2: Information Flows for Validation 

No flow will be shown for this version of the document 

94 Roaming to Other Networks 

« ,rr<?M/GPRS UMTS R99and UMTS RO0CS and GPRS 

inorder to ensure con*a*mty and e^^ 

domain (excluding the VoIP/multunedi^ .domam), * e s ^ m ^ t ; updateth eHSSwimtbecunentsubscnber 

. R-SGW relays all the MAP /^ ^»*B 

...)handlmgCaU/Sessionin Ae2G/RS9CN , ationofthe subscriber data compatible with 

. Or, the service ofaGK m the visited PLMN is useo 
SGW is not impacted in this case. 

. i„ case of a R99 terminal roaming in a MS ^ S ^^q °R59 HLR / SCP and the functions 

R-SGW relays all the MAP / CAP messag« b^J*^^ CN The R00 VLR (inSGSN and/or CS domain) 
(SGSN, . . .) handling Call / Session in the All 1 ^^^^9/CAP R99 received from R99 
or Call / Session handling function is able to mterpret MAPJW* 
HLR /"SCP 



PCT/IB02/02212 
in case of a R99 terminal roanung in ROO nerwoi*. 

is no standard way to have a *fedOC. R99 icquests $ervicc from its Home 

. Either^ordertogetacuswm^dsemc, 

CSCF in its .^-StKSS^ *° — ^ ^ CUS,(OT,Ze 
. Or, the service ofaGK in tnevisucur 

SGW is not impacted in this case. 

wmmmmm 

roaming are for farther study. 

9.4., Roaming Procedures for ROO networks ^ ^ 

roaming. 

The roaming scenarios described are: 

. Roaming within ROO PS domain networks; 

. Roaming from ROO PS dornam networks to 2G/UMTSR99 networks; 

9 .4.2 Overlaid solution to roaming 

The following issues need to be oiscusseo an 

^Pnetworkandntightre^ired.se-ss.onmtheplenary. ^ 
. Supponofn^voice^^ 

plane (e.g. CSCF) and on tne p -jchthave additonal interface (e.g. 

. UMSstmctureandfunc^ 

GRIC CSP) to the clean houses as defined m H.225. toteropeia te. This platform allows ISPs, 

°Sn platform (GRIC CSP) that allows *J««*2 suS Telephony, E-commerce, Internet 
"kos, and'emerging carriers to offer ^ggjSS <U a woridwide membership of over 450 
Roammg, and Internet Faxmg.^ 

major ISPs and telcos in more than 140 C0M ' S, r ^re information on GRIC see 
S^ers and an estimated 40 m^ 
http://www.gric.org/ Routing optmusation for calls ongmate 
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„ a using a DN (Directory Number) in order to bypass the PSTN 

another Release 2000 all IP network and addressed using a v 
has to be discussed. 
. A.so.routmgofMTcallstowardsLNhastobespecified. 

and roaming, services) needs to be addressed. 



^^^^^^^^^^^ 

Also.s.gn ^ Actions wffl have to be implemented. 

Theissuecouldaffectmearchitec^ 

, n>oHHr«« has to be solved as an issue if not yet 
Addressing of multiple PDP flow by means of the same IP address has to be 

stand ardisedforGPRS. Release 2000 all IP network and the vocoder negotiation 

Details regarding the set of vocoders supported m Release 
mechanism need to be investigated. 

. SignalU^PDPflowc^bea^ 

^O^nentsofmultin^diacallshavetobeconttolled 
. is T.120 considered as real-ftme apphcahon, i.e. do l .uu cow 
byaCSCF? 



be discussed. In particular, the presence oi a * 
alternatives evaluated. 

. Provisioning of location-based services (e.g. serv.ee based on geo locan 

architecture need to be considered. 
. QoS and security issues have not been addressed yet 



PCT/IB02/02212 



WO 02/096128 



10 Service Platform Impacts 
10 .1 3GPP Release 2000 Service Architecture ^ 

Note- The architectures in Figure 10-1 ana figure 
shown in the Reference Architecture in Sect.cn 5. 




Figure 10-1: 3GPP Release 2000 service architecture 

. -lifted in Figure 10-l(note that the figure is not meant to be 
The Open Service Architecture consists of three parts, as ulustrated » Figure 
exhaustive of all interrelationships): 



" ~ u- • r> AM3RL providing the CAP interface between serving and 

Within the current 3GPP specifications this is achieved v» CAMEL provutag the 

home network. 
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or more Application Savers; of the service 

for UMTS Release 99 are CAMEL. MExE, SAT and HLR. 



<5) □ □ (51 a f° a " 



Open 
Service 
Architecture 



□ O □ 




• application 

application 
server 

interface 
standardised 
inOSA 

interface 



service 

capability 

server 



terminal 



iiii 



applications 



Figure 4 

Figure 10-2: Overview of Open Service Architecture 

N0 U: Ikis .ay not te in line „ltk tke latest venlon oftHe VHVOSA St^e 2 „ocun,ent 

10.2 IN based Services 

me IN based service is one » m ttfJSyX*5 
When only w Mtafio has » bt suppoitri several options <*«: 

SCP- These interfaces will be used for inter- and intra-networK connecuon*. 
suitable INAP protocol (e.g. CAP). 

^ . i ru a «rf 1GPP Release 2000 network functions, allowing the AS to access the 
3. Provide new interfaces between legacy IN and 3GPP Release zwv 

application in the legacy "SCP. 
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« . ji r a fnt the OoS enabled GPRS network are still available and 
I. shall be noted .hat the Operator Specific Series defined ^fjtr^nce enable the pre-paid charging of the 
apply for the access bearers towards the MM core network. 



GPRS bearer. . 

* ■> i^rtinn 10 2 1) will allow the possibility that existing services can oe 
As indicated in the sections below, option 2 s^»n l0.2^w, ^ £ ^ ^ 3 

upgraded to provide 3G users w.th a seamless trans,t.on o»Marz. ik appropriate to allow 

(Son 10.2 P 2) does not have this advantage carried via option 2 and enhanced/future 

^st^ 

10.2.1 'INAP* based interface between legacy SCP and R00 network 



entities 



Infhisoption.fi.classica^ 

switching function (based on the 23.078 spec.ficau.on ofthegsmSSF) g' 1 ^ 8 cs£ ^ functional entity, called 
SS. Conceptually, a new functional entity is iwgm* g^J" °g ™ ^Rationality, where call control 
a softSSF, can potentially be based on a ^'^^^^cts with theOSE via CAP and interacts w,th 
biBJng and database functions are reuuied or e ^"^S &e CSOT or via an open interface based on OSA 
the CSCF either via an internal interface ^"g*^ ^ Zges to CAP can be expected to take into 
concepts (if the softSSF is deployed as a J^SISSS « » offer its services via defined open interfhees 
account the impact of the underlying IP ca ^ c ^.^S * X CSE via the CAP interfaces to the SGSN and the 

ScF« 



VHE/OSA 
: Application 
• Interface 




Fi B ure 10-2 Functional Architecture to support option 2 
10.2.1.1 Advantages 

and ownership costs allowing existing famihar 2G services to be provioea 

. , Tk-r. ar , several IN/CAMEL services already 
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10.2.1.2 Disadvantages 

a ™Htv 'cnftW which provides the necessary mapping between the CSCF and the CSE. 

♦ Introduces new functional entity sorter , wnicn piuvmw u-* j r M . already 

further study. 

10 2 2 New open interface between legacy SCP and R00 network entities 

ThisoptionadoptsmeOSAprm^^^ 

defined APIs that allow applications . separate ^^ ^ tO U ^J ~Ste to applications designers with 
approach allows the service features that are provided by I *«^a ' ™ * service capabilities in UMTS 
oShavingdetaUedknowledgeofAesp^ 

phasel, and CAMEL j^^^^SS i- se^om^nenScould * ™ Control, 
defined open interfaces, and implements these by using GSM/UMTS protocols . 

service features offered in the CSCF. 

a-u «n ii «i«t These APIs will enable the users to access service logic via the UE and 
APIs supporting client-server models will exist. These Aris ww cna 

specialist servers (e.g. MexE). The interface these specahst servers and the CSCF is for further stuay 




Figure 10-3 Functional Architecture for option 3 
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10.2.2.1 Advantages 

• An open interface based on OSA concepts. APIs that may interface with the CSCF and the CSE are expected to 
become available allowing specific protocols to be hidden from the service/application designers 

• Easier deployment of new/enhanced services for multimedia applications. 

1 0.2.2.2 Disadvantages 

• When considering existing CSE based services, little re-use is made of already standardised protocols, services and 
processes. More significantly, new processes and protocols must be re-defined and re-implemented for services that 
already exists, increasing development and ownership costs. 

• Requires new applications on an application server to be created in order to support legacy services. 

• Impact on the legacy CSE and services considered greater than option 2. 

1 0.3 Issues requiring further contributions 

The following issues require further contributions: 

• Applications may reside not only in Application Servers (AS) but also in temiinals. 

• Options for sharing applications or parts of them between AS and terminals 

• Which elements, beside the CSCF, will provide API for application design (aligned with VHE/OSA) 

• Terminal shall also provide API for application design (aligned with MExE) 

• Which new Service Capabilities/Service Capability Features are needed for 3GPP Release 2000 (e-g. WIN) 

• Specific implementation cases of the proposed architecture should be provided. 

• If and how 3GPP Release 2000 service features could be made accessible to 2G terminals via 2G networks 

• If and how 3GPP Release 2000 service features could be made accessible to dual mode 2G/3G terminals via 2G 
networks 
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1 1 Security 

There will be a common authentication scheme for the terminals operating in the all-IP mode, which will be SIM/USIM 
based. It is required that all-IP terminals will be able to register and provide basic service when used with a 3GPP 
SIM/USIM. 



12 Work Plan 

12,1 Milestones for Release 00 

3GPP has the objective of producing the second release of specification for UMTS by the end of 2000. The project 
management for this work will need to include the elements of work package definition, the interdependency of these 
work packages and their scheduling. As the work is undertaken in the various TSGs and WGs in 3GPP there will need to 
be agreement across these groups on the overall plan. Subsequent communication between these groups on such issues 
as changes to schedules and requirements will be essential. An additional task relating to communication is the 
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4 ^rhnical oroblems in the implementation at an early stage. The 

need lo 6e wriffed »y TSG-S2. 
•12 1 1 Release 00 milestones 

3GPP All-IP network feasibility study started 

TSG-S2 R00 Ad Hoc will submit the results of the TSG-S2 for approval 



July 99 
Sept 99 
Oct 99 



Oct 99 

Dec 99 

Dec 99 
Jan 00 

JanOO-DecOO 
Dec 00 



After TSG-S2 approval, TSG-S2 R00 Ad Hoc Group results will be submitted to TSG-S for 
approval 

A ftCT TSG-Sa P p ro valP^ 

started at TSG-S2 project planning ad hoc groups Obese groups nav cq 
participation from all relevant TSGs/WGs). 

After TSG-S2 approval the detailed workplan for R00 (including all-IP network option) will 

be submitted to TSG-S for approval. 

Release 00 service requirements available 

TSG-SA2 completes first draft architecture for all-IP network. 

Plan 



Release 00 specifications completed including all-IP option 



. f .„ form the basis of the planning for releases beyond R99. The reviewed first 
A high level PERT chart is ^^£2^^ a^£b3ore the end of 1999. 
drafts of the service and architecture speculations snuui 

1 2.1 .2 Detailed activity plan 



Date 

August 23 - 27 



Meeting group 

sf 



September 13 - 17 



Late September/early 
October 



S2 



S2R00AdHoc 
Group meeting 
(provisional) 



Proposed activity 
Progress architectural study 



-f • t s2 activity on R00 - Finalize the requirements tor the 
Statural sLTSd identify the finalize the proposed 
R00 architecture at the TSG-S2 R00 ad hoc group. 



Possible refinements to the outcome ot tne aa noc poup 
Review input on service requirements for ROO 



Approve the results of TSG-S2 ROO Ad HocGroup 

■ Slart ,he specification of the architecture, and detailed work plan. 

Initiate the S2 project coordination adhoc groups work for R00 Won 
proved frcmTSG-SA Plenary nswell as results from other 



WO 02/096128 



PCT/IB02/02212 




WO 02/096128 



History 



Document history 


VO.0.0 


July 1999 


Creation of document 


V0.0.1 


1 1 Aug 1999 


Updated after R2000 Ad Hoc Swindon, 10-1 1 th August. 

Scope is clarified and new text added to requirements, Service Platform sections 
and a new architecture sub-section on support for R99 terminals. 

Architecture changes: new CSCF <-> CSCF interface. MGW split into MGW and 
Transport signalling gateway. SGW to legacy network labelled as roaming 
gateway. 


VO.0.2 


1 Sept 1999 


Updated after R00 Ad Hoc, based on tdocs s2k99030, s2k9903 1, s2k99032, 
s2k99035, s2k99045, s2k99049 


VO.0.3 


6 th Sept 1999 


Updated with new sections reviewed by e-mail. Contains marked changes from 
vO.0.2 


V0.1.0 


22 Sept 1999 


Updated as per meeting week beg. 13 th Sept (Bonn). New text on handover and IP 
header compression /stripping. Definitions on Mc reference point and on the 
Media Gateway function al blocks. 


VO.l.i 


28 th Sept 1999 


Draft for Ad Hoc Helsinki, changes include addition of HSS in section 5, agreeed 
solution for support of CS terminals. 


VO.1.2 


29 th Sept 1999 


2 nd draft for Ad Hoc Helsinki, changes include addressing editor's notes in section 
9, addirtion of text to sections on QoS and Security and new subsections to service 
Platforms 


V0.1.3 


30 th Sept 1999 


Interim draft at R00 Ad Hoc, Helsinki 


VO.1.4 


I* Oct 1999 


Final draft for approval 


V.l.0.0 


7*0*1999 


Prepared for presentation at SA#5. Technical content identical to v.0.1.4 



113 




PCT/IB02/02212 



WO 02/096128 



114 



PCT/IB02/02212 



CLAIMS ; 

1 A packet switched environment, including a functionality of 
a'presence server in an application and services environment. 

2 The Packet switched environment of claim 1 wherein the 
presence server receives a REGISTER message from an 
interrogating call state control function in the same network. 

3 The Packet switched environment of claim 2 wherein the 
serving call state control function of the presence server 
network further receives the REGISTER message. 

4 The Packet switched environment of claim 2 or claim 3 
wherein the presence server receives SUBSCRIBE message from 

ot- a te control function in the same 
the interrogating call state control 

network . 

5 The Packet switched environment of claim 4 wherein the 

rall stat e control function receives the 
interrogating call state coui. 

fr-om a serving call state control function 
SUBSCRIBE message from a serving 

in a subscribers home network. 

i The Packet switched environment of claim 5 wherein the 
, er ving cell state centre! function receives the SUBSCRIBE 
message from a proxy call state control function In a 
subscribers home network. 

, The Packet switched environment of claim 6 -herein the 
proxy call state centre! function receives the SUBSCRIBE 
message from the subscriber. 

. The Packet switched environment of any one of claims 2 to 7 
, wherein the presence server provides a NOTIFY message to the 
interrogating call state control function of the subscriber s 
network. 

9 The Packet switched environment of claim 8 wherein the 
interrogating call state control function provides the NOTIFY 
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m a oroxy call state control function of the 
5 message to a proxy 

subscriber network. 

10 The Packet switched environment of claim 9 wherein the 
proxy cail state controi function provides the Norm message 
to the subscriber. 
10 11 The Packet switched environment of claim 1 wherein the 
presence server receives a plurality of SUBSCRIBE signals from 
a respective plurality of subscribers in a subscriber network. 

12 The Packet switched environment of claim 11 wherein each 
subscriber provides a SUBSCRIBE message to a proxy call state 

15 control function of the subscriber network. 

13 The Packet switched environment of claim 12 wherein the 
proxy call state control function of the subscriber network 
forwards the respective SUBSCRIBE messages to a serving call 
state control function of the subscriber network. 

20 14 The Packet switched environment of claim 13 wherein the 
serving call state control function of the home network 
provides the respective SUBSCRIBE messages to an interrogating 
C all state control function of the presence server network. 

15 The Packet switched environment of claim 14 wherein the 
25 interrogating call state control function provides the 

respective SUBSCRIBE messages to the presence server. 

16 The Packet switched environment of any one of claims 11 
to ' 15 wherein the presence server provides a single SUBSCRIBE 
message to a serving call state control function of the 

30 presence server network. 

17 The Packet switched environment of claim 16 wherein the 
presence server receives s single NOTIFY message from the 
serving call state control function. 
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. „ The Packet switched environment of dai« 17 

Tresence server generates e HOTIPV message for each respective 
user subscriber. 

l9 The Packet switched environment o £ claim 1. . the 

Lality of NOTIFY message, are received by the rnterrogst^g 

l0 cail state control function of the subscriber networb. 

20 . The Pacbet switched environment of claim IP wherei^the 
interrogating call state control function forwards the NOTIFY 
Images to a serving call state control funct.cn of the 
subscriber network. 

15 21 . The Pacbet switched environment of claim 30 wherein the 
serving call state control function forwards the 
Tsages to a proxy call "ate control functron of the 
subscriber network. 

22 The Pacbet switched environment of claim 2 1 wherein the 
20 ^oxy call state control function forwards the NOTIFY messages 
to the respective subscribers. 

22 The Pacbet switched environment of claim 2 wherein the 
"esenc server receives a REGISTER message from a servrng 
feu state control function in the presence server networb 
25 network. 

24 . The Pacbet switched environment of claim " -herein ^ 
aervin g call state control function receive, the W«B 
Z.ge from an interrogating call state control functron of 
the presence server network. 
,„ 25 The Pacbet switched environment of claim 2 4 wherein a 
30 .Lcriher provides a SUBSCRIBE message to a proxy call state 
control function of the subscriber networb. 

26 The Pacbet switched environment of claim 2S wherein the 
vJLl state control function of the subscriber network 
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- servinq call state control 

5 forwards the SUBSCRIBE message to a serving 

function of the subscriber network. 

27 . The Packet switched environment of claim 13 whereir . the 
serving call state control function of the subscriber network 
™es the SUBSCRIBE message to an interrogating call state 
10 control function of the presence server network. 

28 T he Packet switched environment of claim 14 wherein the 
interrogating call state control function provides the 
interrogating serv ing call state control 

respective SUBSCRIBE messages to a serving 

function. 

The Packet switched environment cf claim 2B wherein the 
" elrvinHaU Ite centre! function proves the SUBSCRIBE 
message to presence server. 

30. The Backet switched environment of ciaim „ wherein the 
presence server provides NOTIFY messaae to the servmo call 

20 state control function. 

31 . T he Packet switched environment of claim 30 wherein the 
N0TI PY message is received by the interrogating call state 
control function of the subscriber network. 

32 . The Packet switched environment of claim » — ^ 

25 interrogating call state control function forwards the NOTIFY 

-o a serving call state control function of the 
message to a serving 

subscriber network. 

33. The Packet swiped environment of claim 32 w^ein the 
serving call state control function forwards the WW 

^ ca u state control function of the 
30 message to a proxy can 

subscriber network. 

3, The Backet switched environment or claim 33 wherein the 
P roxv call state control fenction forwards the HOTXBV messa.es 
to the subscriber. 
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•-ohed environment of any preceding claim, 
5 35. The packet switched nv ^ 

wherein the environment is an i 
environment . 

. u a rework of claim 35 wherein the 
The Dacket switched networK oi 

10 all-IP telecommunications network. 
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H04Q 3/00, H04Q 7/24 



Applicant 

Nokia Corporation et ai 



a. 
b. 
c. 
d. 
e. 



j Q The subject mailer of the international application relates to. 
n scientific theories, 
mathematical theories, 
plant varieties. 

1-1 processes and the products or such processes, 
f riscl«nies, rules or methods of doing business. 
g H schemes,rulesormetl,odsorperfonningpurc1y"u : n.alacts. 

h n schemes, rules or methods or playing games. 

H me ,hodsfor.rea.mentortheh,nnanbodybysur 8 enortherapy. 

H methods for treatment or the animal both' by surgery or therapy. 
□ diagnostic methods practised on the human or animal body. 

prevents a meaningful search Trom being carried out: 

□ it does not comply with the prescribed standard 

□ it is not in the prescribed machine readable form 



i. 
j 

k. 
L 



2.(21 



□ 



4. Further comments: 
see next sheet 



Name and mailing address of the International Searching Authority 
- European Pttent Office, P.B. S81S Patentlaan 2 
NL-2280 HV RiMik 
Tel. ( + 31-70) 340-2040, Tl. 31 651 epo nl. 
Fax: (+31-70> 340-3016 




Authorized officer 

Peter Hedman/EK 
Telephone no. 08-782 25 00 



PCT/1SA/203 (July 1998) 



4 



International application. No. 

PCT/IB02/022I2 



is sought (See PCT Art. 6). 



FaimPCT/ISA/210 



PATENT COOPERATION TREATY 

PCT 



INTERNATIONAL PRELIMINARY REPORT ON PATENTABILITY 

(Chapter H of the Patent Cooperation Treaty) 



Applicant'6 or gent's file reference 
301864WO/KCS 



(PCT Article 36 and Rule 70) 
FOR FURTHER ACTION SeeFonnPCT/lPEA/416 



International filing date (day/month/year) 
09.10.2002 



International application No. 
PCT/IB 2002/004381 

International Patent Classification (IPC) or national classification and IPC 

H04Q 7/38 



Applicant 

Nokia Corporation et al 



AuS under Article 35 and transmitted to the applicant according to Arttclc 36. 

2. This REPORT consists ofa total of _3 sheets, Eluding this cover sheet 

3. This report is also accompanied by ANNEXES, comprising: 
a. □ to the applicant and to the International Bureau) a total of 



sheets, as follows: 



(sent to the applicant ana to tne lmernuuu,™ — . . . 

□ SSSSsassisisaBSs ses ass i» 

Supplemental Box. 

h PI (sent to the International Bureau only) a total of (indicate type and number of electronic carri^)) 
fc U (senttothelntema jC<mteilltaga Bstbgand/or ^^^^ 

^dablefbtmonly.asind^^ 

Administrative Instructions). ' 



4. This report contains indications relating to the following items: 
Box No. 1 Basis of the report 
Priority 

Lack of unity of invention 

Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial 
applicability; citations and explanations supporting such statement 
Box No. VI Certain documents cited 
BoxNo.Vll Certain defects in the international application 
Box No. VIII Certain observations on the intonational application 



□ 
□ 
□ 

□ 
□ 
□ 



Box No. 11 
Box No. HI 
Box No. IV 
Box No. V 



[ International application No. 
INTERNATIONAL PRELIMINARY REPORT ON PATENTABILITY pcr/lB 2002 / 0 04381 



Bra No. I Basis of the report 

v ^ is based on the international application m the language in which it was filed, unless 
1. With regard to the language, this report is based on the intemauwuu <w 
otherwise indicated under this item. 

which is the language of a translation funded for the purposes of. 

□ international search (under Rules 123 and 23.1(b)) 

□ publication of the international application (under Rule 12.4) 

□ intonational preliminary examination (under Rules 55.2 and/or 55.3) 

,• > a;. is based on (replacement sheets which have been 

and are not annexed to this report): 



2. 



□ 



the international application as originally filed/furnished 
the description: 



s originally filed/furnished 



received by this Authority on 
received by tiiis Authority on 



| | the claims: 



as originally filed/furnished 

s amended (together with any statement) under Article 19 



pages* 



received by this Authority on t 
received by this Authority on 



□ 



the drawings: 
pages 



as originally filed/fumished 



received by tins Authority on 
received by this Authority on 



Q [ seouenc lining and/or any related table( S ) - see Supplemental Box Relating to S^encc Listing. 
Q The amendments have resulted in the cancellation oft 

□ 
□ 
□ 



□ 

□ 



the description, pages 

the claims, Nos. . — - 

the drawings, sheets/figs 

the sequence listing (specify): 

any table{8) related to the sequence listing (specify): 



made, 
70.2(c)), 

□ 
□ 
□ 
□ 



the description, pages 
the claims, Nos. 



the drawings, sheets/figs 
the sequence listing (specify) 



Q any table(s) related to the sequence listing (spec®): 



INTERNATIONAL PRELIMINARY REPORT ON PATENTABILITY 



International application No. 
PCT/IB 2002/004381 



Box No. V Reasoned statement under 

^« d explanations supporting such statement 



Article 35(2) witb regard to novetty, inventive step or industrial applicability; 



1. Statement 



YES 

Novelty (N) Claims 1-25 " N0 

Claims ■ 

YES 

Inventive step (IS) Claims 1- 2 5 ■ NO 

Claims • ; " " 

YES 

Industrial applicability (IA) Claims 1-25 ~ " NO 

Claims . — " 



2. Citations and explanations (Rule 70.7) 

The claimed invention provision of a presence 

" T he claimed invention relates to provision o f 
service in a communication system. 

Document cited in the International Search Report: 
Dl: WO 02096128 A 
D2: WO 0243351 A 
D3: EP 1248484 A 
D4: WO 0172055 A 

The cited documents ^T^^TS ^disllo^by any 
The invention defined in claims 1-25 is noc 

of these documents. indication that would 

industrially applicable. 



* 



The demand must be filed directly with the competent International Preliminary Examining Authority or, if two or more Authorities are competent, 
with the one chosen by the applicant The full name or two4etter code of that Authority may be indicated by the applicant on the line below: 

IPEA/J5E 



PCT 

DEMAND 

under Article 31 of the Patent Cooperation Treaty: 
The undersigned requests that the international application specified below be the subject of 
international preliminary examination according to the Patent Cooperation Treaty and 
hereby elects all eligible States (except where otherwise indicated). 



CHAPTER II 



Identification oflPEA 


Date of receipt of DEMAND 


Box No. I IDENTIFICATION OF THE INTERNATIONAL APPLICATION 


Applicant's or agent's file reference 

301864WO/KCS 


International application No. 

PCT/IB02/04381 


International filing date (day/month/year) 
9 October 2002 


(Earliest) Priority date (day/month/year) 



Title of invention 

A COMMUNICATION SYSTEM 



Box No. II APPLICANT^) 



Name and address: (Family name followed by given name; for a legal entity, full official designation. 
The address must include postal code and name of country) 

NOKIA CORPORATION 
KEILALAHDENTIE 4 
FIN-02150 ESPOO 
FINLAND 



Telephone No. 



Facsimile No. 



Teleprinter No. 



Applicant' s registration No. with the Office 



State (that is, country) of nationality: 

Fl 



State (that is, country) of residence: 

Fl 



Name and address: (Family name followed by given name; for a legal entity, fill official designation. The address must include postal code and name of country.) 

LEPPANEN, Eva-Maria 
Veisunkatu 82 C 14 
33820 Tampere 
FINLAND 



State (that is, country) of nationality: 

Fl 


State (that is, country) of residence: 

Fl 


Name and address: (Family name followed by gjtven name; for a legal entity, fa 


tU official designation. The address must include postal code and name of country.) 


KALLIOKULJU, Juha 




Jokioistentie 5 




37470 Vesilahti 




FINLAND 





State (that is, country) of nationality: 

Fl 



State (that is, country) of residence: 

Fl 



] X[ Further applicants are indicated on a continuation sheet 



Form PCT/IPEA/401 (first sheet) (March 2001; reprint July 2003) 



See Notes to the demand form 




□ Further applicants are indi cated on another continuation sheet 
^CT/IPEA/401 (continuation sheet) (March 20O1; repnm M03) 



See Notes to the demand form 



Form 



International application No. 

PCT/IB02/04381 



Sheet No. .3. 

BoxNo.IIl AGE NT OR COMMON REPRESENTATIVE; OR ADDRESS FOR CORRESPONDENCE 
The following person is g] agent □ common representative 
and EI has been appointed earlier and represents the apphcant(s) also for inte^^ 

n * hereby appointed, specifically for the pK ^«re before the Internal Prelimi^ry Exarnidn^ 
1 — 1 the agent(s)/common representative appointed earlier. 



h- _ . /b/jowerf m, given name; /or a fega/ entity, full official designation. 

Name and address. <™^^JZZdu&foital code mi name of country.) 

STYLE, Kelda Camilla Karen 
PAGE WHITE & FARRER 
54 Doughty Street 
London WC1N2LS 
United Kingdom 



Telephone No. 

(020)7831-7929 



Facsimile No. 

(020)7831-8040 



Teleprinter No. 



Box No. IV BASIS FOR INTERNATIONAL PRELIMINARY EXAMINATION 



Statement concerning amendments: * 

1. The applicant wishes the international preliminary examination to start on the basis of: 
g] the international application as originally filed 
the description H as originally filed 

| | as amended under Article 34 

the claims Ej as originally filed 

□ as amended under Article 19 (together with any accompanying statement) 

| | as amended under Article 34 

the drawings El as originally filed 

\ | as amended under Article 34 

2 □ The applet w,shes any amendment to 0k clarms under Article 19 to be cons.dered as reversed. 

box may be marked only where the time limit under Article 19 has not yet expired.) 
. where - i*. » -M ^S^SSS^f^SSSS^SS^S^ ' 

or the internatio nal preliminary examination report, as so amended. 

Language for the purposes of International preliminary examination: .English. 

[g which is the language in which the international application was filed. 

□ which is the language of a translation furnished for the purposes of international search. 

□ wW ch is me language of publication of the international application. . 
Q which i s the language of the translation (to be) famished for the purposes of international prehmmary exam-natron. 

Box No.V ELECTION OF STATES 

The applicant hereby elects all eligible States 

thePCT) 

excluding the following States which the applicant wishes not to elect: 



is, all States which have been designated and which are bound by Chapter U of 



Form PCT/IPEA/401 (second sheet) (March 2001; reprint July 2003) 



See Notes to the demand form 



Sheet No. .4. 



International application No. 

PCT/IB02/04381 



I Box No. VI CHECKLIST 



The demand is accompanied by the following eiemenu,, w ^ ' 
Sx^/foX P ^s of international preliminary exarmnaUon. 

1. translation of international application ■ 

2. amendments under Article 34 

3. copy (or, where required, translation) of 
amendments under Article 19 

4. copy (or, where required, translation) of 
statement under Article 19 

5. letter 

6. other (specify) 



For International Preliminary 
Examining Authority use only 





received 


not received 


sheets 


□ 


□ 


sheets 


□ 


□ 


sheets 


□ 


□ 


sheets 


□ 


□ 


sheets 


□ 


□ 


sheets 


□ 


□ 



I The demand is also accompanied by the item(s) marked below: 
1. 12 fee calculation sheet 

2. □ original separate power of attorney 

3. Q original general power of attorney 

4. Q copy of general power of attorney; 
reference number, if any: 



5. □ statement explaining lack of signature 

6. Q sequence listings in computer readable form 

7. □ tables in computer readable form related to 

sequence listings 

other (specify): 



STYLE, Kelda Camilla Karen 
Authorised Representative 



For International Preliminary Examining Authority use only • 



1. Date of actual receipt of DEMAND: 

2. Adjusted date of receipt of demand due 
' to CORRECTIONS under Rule 60.1(b): 

, n Tfcedateofteceiptofthedemandis™ Q ^STJoSS" 

3 - □ from the priority date an d item 4 or S, below, does not apply. 

4 - I | Rule 80.5. 




Demand received from IPEA on: 
Form'pCT/IPEAWl Oast sheet) (January 2003; reprint July 2003) 



See Notes to the demand form 



* 



PCT 



CHAPTER II 



FEE CALCULATION SHEET 

Annex to the Demand 

_ For International Preliminary Examining Authority use only 




Form PCT/IPEA/401 (Annex) (March 2001; reprint July 2003) 



See Notes to the fee calculation sheet 



* 



* 



PCT 

REQUEST 



The undersigned requests that the present 

international application be processed 
according to the Patent Cooperation Treaty. 



Box No. X TITLE OF INVENTION 
A COMMUNICATION SYSTEM 



. For receiving Office use only ■ 



International Application No. 



International Filing Date 



Nl f receiving Office and "PCT International Application" 



Box No. II APPLICANT 



j""] This person is also inventor 



NOKIA CORPORATION 
KEILALAHDENTIE 4 
FIN-02150ESPOO 
FINLAND 



Telephone No. 



Facsimile No. 



Teleprinter No. 



Applicant's registration No. withthe Office 



State (thai is, country) of nationality: 
Fl 



State (that is, country) of residence: 
Fl 



This person is applicant 
for the purposes ofc 



□ all designated R71 ^ designated States except 
au^signmcu ] X| the Unfed States of America 



the I jmted states I — I ^ States indicated in 
ofAnS onty LI the Supplemental Box 



|— | the United States 



'^Nn.m FURTHER APPLICANTS) AND/OR (FURTHER) INVENTOR{S^ 



LEPPANEN, Eva-Maria 
Veisunkatu 82 C 14 
33820 Tampere 
FINLAND 



This person is: 

, |~[ applicant only 
|)?| applicant and inventor 



□ inventor onl> 
is marked, i 



Applicant's registrarionNo.wi&the Office 



State (that is. country) of nationality: 
Fl 



I State (that is, country) of residence: 

Fl 



ThisperMnUappiicant pi fl**-' US ^ME^ IB »»» □ 
for the purposes of: I — ' bmies — ~~ 



the States indicated in 
the Supplemental Box 



The person identified below is hereby/has been W9*J**&? * bchalf 
of th?^pplicant(s) before the competent International Amhonncs as. 



□common 



| representative 



STYLE, Kelda Camilla Karen 
PAGE WHITE & FARRER 
54 Doughty Street 
London 
WC1N2LS 



Telephone No. 

+44 (0)20 7831 7929 



Facsimile No. 

+44(0)20 7831 8040 



Teleprinter No. 



Agent 's registrationNo. with theOflice 




* 



* 



Sheet No. ...2... 



j fLZm 9 u<** should not be included in the request. 
If none of the following sub-boxes is used, this sheet snouia not 




BoxisthtappUcant* State(tkctis. country) afresh 

KALLIOKUUU.Juha 
Jokioistentie 5 
37470 Vesilahti 
FINLAND 



This person is: 

applicant only 

applicant and inventor 

□ inventor only (If this check-box 
is marked, do not fill m below.) 



Applicant's registration]*), with the Office 



State (that is. country) of nationality: 

Fl 



State (that is, country) of residence: 

Fl . 



^nersonisaonlicant pj aH designated ^ * ft^^^S* ^ 
for the purposes of: I — I oiaws >— i ' 



the States indicated in 
the Supplemental Box 



LONNFORS, Mikko 
Hameentie 70 C 49 
00550 Helsinki 
FINLAND 



This person is: 

[ | applicant only 

^) applicant and inventor 

□ inventor onWflr^^-*ff 
is marked do not fill m below.) 



Appiicant'sregistrationNo.withtheOfGce 



State (that is, country) of nationality; 

Fl 



State (that is, country) of residence: 
Fl 



for the ourposes of: I — I * raws — ■ 



for the purposes 



Name and address: 
The " 
BaxIstheappHeant's 



KISS. Krisztain 
Saastajankatu 13C 14 
33840 Tampere 
FINLAND 



applicant only 
fjfl applicant and inventor 

□ inventor only (If this check-box 
is marked, do not fill in below.) 



Applicant's registrationNo. with theOffice 



State (that Is. country) of nationality. 

HU 



State (that is. country) of residena 
Fl 



This person is applicant Fl£*^ naSSS» glS^gr 
for the purposes of: I — * aww * i — *~ 



the United States f— I the States indteaa^m 
of America only l_l the Supplemental Box 



Name and address: f»«-5/*^^ 



This person is: 
Q applicant only 
Q applicant and inventor 

□ inventor only 0/** 
is marked do not fill in below.) 



Applicant's registration No. with theOffice 



State (that is, country) of nationality: 



| State (that is, country) of residence: 



for the ourposes of: I— 1 3 — 



for the purposes 



j~| Further applicants and/or (further) 



inventors 



are indicated on another continuation sheet 



Form 



PCT/RO/101 (continuation sheet) (March 2001; reprint January 2002) 



See Notes to the request form 



* 



Box No. V DESIGNATION OF STATES 



SbeetNo. ...3.- 



Kris?--. . «. o^.. "^^tr^tss'ss^ 

State which is a Contracting irate oi me o= 

jpacfc on AMrfOHs) • • • ■ • • Belarus KG Kyrgyzstan, KZ Kazakhstan, MD Republic of Moldo^ 

BY * aaia *' ottoState 'which U a Contracting State of the Eurasian 



» EA EnrasUn Patent: AM A^J^Az^ 



Patent Convention and of the PCT SwitK rUnd and Liechtenstein, CY Cyprus, DE Germany. 

B EP European Paten.: AT £f* ,2ISi«a^«I^W.WJ-^ 



other State which is a Contracting State of 

WiV, WMJiiawi f „ ppr 



B AE United Arab Emirates 
QB AG Antigua and Barbuda 

H AL Albania 

B AM Armenia 

B AT Austria 

B AU Australia 

B AZ Azerbaijan 

» BA Bosnia and Herzegovtaa 

BBB Barbados . . . H KG Kyrgyzstan 

B BG Bulgaria - Denwcratic Peop t e ' s Republic 

H BR Brazil * ofKorea 

B BY Belarus . 



18 NZ New Zealand 
„ _ . . . B OMOmaa 

gHRCroana g| PH Philippines . . 

BPL Poland 

B ED Indonesia . B PT Portugal .. . 

Israel 

India 

Iceland 

Japan 



B IL 

Bus 
B is 

. B jf 



B RO Romania 
B RU Russian Federation . 



18 SB Sudan 
B SE Sweden 
B SG Singapore 
. B SI Slovenia . . 
B SK Slovakia . . 



BcbrUS BKR Republic ofKorea £ • 

B BZ Belize T_L.u^ B SL Sierra Leone . 



VI d B KZ Kazakhstan 

BCN China % 



B CO Colombia 
B CR Costa Rica. 
B CU Cuba . 



B LR Liberia 

B LS Lesotho 

B LT Lithuania 
B LU Luxembourg 



50 TJ Tajikistan 

B TM Turkmenistan 

B TN Tunisia 

. B TR Turkey 

B TT Trinidad and Tobago 



B MA Morocco ■ 



B MD Republic of Mo.dova . . . ..... ■ g - United S«es of America 



gCZ Czech Republic J 

B DE Germany • 

B DK Denmark 

B DM Dominica 

gDZ Algeria... B MGMadagascar 

B EC Ecuador g MKThe fonncr Yugoslav Republic of 

g EE Estonia Macedonia 

g ES S ? a ; n ! BMN Mongolia 

B FI Finland 

B GB United Kingdom 
B GD Grenada 

B GE Georgia 

B GH Ghana 



B TZ United Republic of Tanzania 

B UA Ukraine 

B UG Uganda 



B UZ Uzbekistan . . 
B VN Viet Nam... 
B YU Yugoslavia . . 
„ B ZA South Africa . 

gMV^alawi £ ZM Zambia 

B MX Mexico 

B MZ Mozambique 
B NO Norway 



BZW Zimbabwe. 



of mis sheet: 



— T T— the aBD Hcant also makes under Rule 4.9(b) all 
mode above, theappnean ^ Supplemcntal Box ^ bcing 



;.ul. ^-..X™. which would be permitted under Ac PCT except any s ^ Kbject tocoofirmati 



See Notes to the request form 



Form PCT/RO/101 (second sheet) (January 2002) 



# 



f is not 



Sheet No^ 

used, this sheet should not be Included in the request 



. IfManyof^Bores^BM^^^ 
ispecial continuation box *P™?£™^? C Vntfiuo<ton 

particular: 

0) If more than ^^"'"Z'J^^ZC^ 
cf residence is indicated below; 

applicant; 

named person is inventor; 



JENKINS, Peter David (GB) 
DRIVER, Virginia Rozanne (GB) 
DANIELS, Jeffery Nicholas (GB) 
STYLE, Keida Camilla Karen (GB) 
SHACKLETON, Nicola (GB) 
SLINGSBY, Philip Roy (GB) 
HILL, Christopher Michael (GB) 
RUUSKANEN. Juha-Pekka (Fl) 
WILLIAMS, David John (GB) 
EVANS, Marc Nigel (GB) 
EVENSON, Jane Harriet (GB) 
PALMER, Roger (GB) 
RICHARDS, David John (GB) 



All of: 

Page White & Farrer 
54 Doughty Street 
London WC1N2LS 
United Kingdom 



^^^^^^^ 
information as required m Box No. IV. 

Box No. V and S*nam r^I^onZof 
andaftertkenameofeaehsuch^oi^^)^^^ £ 

the parent title or parent application ™t£tote °J 8^> n J 
Z parent title or filing of the parent application. 

tZ^rtA^r^A^^' earlier 
fpp^n L ZJtU of information as required 
&BoxNo.VI. 

mssssssm 

State so excluded 



Form 



PCT/RO/lOl (supplemental sheet) (March 2001; reprint January 2002) 



See Notes to the request form 



Sheet No. ..5--» 



Box No. VI PRIORITY CLAIM 



The priority of the 



following earlier application^) is hereby ckimed: 



Filing date 
of earlier application 
(day/month/year) 



Number 
of earlier application 



Where earlier application is: 



nauor*. application: | xegi^al app^c-- 1 inte^^tion: 




Q Further priority claim, are indicated m the Supplemental Box. 



if the earlier application w filed™* the Office whichfor tnepurpo, n otheriSee 

^ VeaS - n wn n iB(2 ) □ i«em(3) □ «-W □ ittm(S) ^ Supplement* Box 

Imtetrial or or* Member tfthtnortairaaevs 



Box No. VII INTERNATIONAL SEARCHING AUTHORITY 



ISA/ 



EP 



Request to use results of earlier search; reference to that search 

International Searching Authority): 
Date (day/month/year) 



(if an earlier search has been carried out by or rented fro*, the 



Country (or regional Office) 



BoxNo.Vm DECLARATIONS 



a i» Nos V1U <i) to (v) (mark the applicable 

Q BoxNo.Vlfl(i) 
□ Box No. VIII (ii) 

Q BoxNo.Vtn(iii) 

Q Box No. VIII (iv) 

Q BoxNo.VIll (v) 



Number of 
declarations 



Declaration as to the identity of the inventor 

Declaration as to the applicant entitlement, as at the international filing 
date, to apply for and be granted a patent 

Declaradonasto^ : 
daU to claim the priority of the earlier application 

Declaration of inventorahip (only for the purposes of the designation of the 
United States of America) 



Declaration 



ioaastonon^judicialdis^^ 



Form 



PCT/RO/101 (third sheet) (March 2001; reprint January 2002) 



See Notes to the request form 



• 



* 



Box No. DC 



Sheet No. ..ft 
CHECK LIST; LANGUAGE OF FILING 



6 

19 
4 
1 
5 



35 



This international application contains: 

(a) the following number of 
sheets in paper form: 

request (including 
declaration sheets) : 

description (excluding 
sequence listing part) 

claims 
abstract 
drawings 

Sub-total number of sheets 
sequence listing part of 
description (actual number 
of sheets if filed in paper 
form, whether or not also 
filed in computer readable 
form; see (b) below) _ 

Total number of sheets • vivf 
(b) sequence Usting part of description filed in 
computer readable form 

(i) □ only (under Section 801 (aXO) 

(ii) □ in addition to being filed in paper 
form (under Section 801(a)(n» 

Type and number of carriers @*tete> 
CD-ROM, 0>R or other) ™^&*}*, 
seouence listing part is contained (additional 

bTinteatedunder item 9(H), m 
right column)'. 



v rii/i^« _ . 

■^"^lional application is accompanied ^efotowng 



Number 
of items 



\ Q fee calculation sheet 
2. □ original separate power of attorney 
3 Q original general power of attorney 

5 □ statement explaining lack of signature 

priority document) identified in Box No. VI as 

item(s): 



LICU1W 

7. Q translation of international application into 
(language)'- 



{language 

g n separtteindiwtionscc^msdeposiwdm.ctoorgan.sm 

or other biological matenal .. 

international application) 

the copy for the purposes of international search unoer 

» aaesKSSBSsaass- 

mentioned in left column 
10. n other (jpecife)- 



Figure of the drawings which 
should accompany the abstract: 



I Language of filing of the 

international application- 



any tne ao snact. j . 



STYLE, Kelda Camilla Karen.. 



.(Professional 



. For receiving Office use only . 



Date of actual receipt of the purported 
international application: 



1 Corrected date ©factual receipt due to later but 
SSr^eived papers or drawings .completing 
SSSiSSd mternational application^ 



2. Drawings: 
Q received: 

f \ not received: 



4 Date of timely receipt. of ^ required 
corrections under POT Article 11(2): 



5. International Searching Authority 



(if two or more are 



competent): Lb A / 



□ Transmittal of search copy delayed 
until search fee is paid 



For international Bureau use < 



# 



PCT 



PCT/IB2002/004381 



PATENT COOPERATION TREAT 

From the INTERNATIONAL BUREAU 



NOTICE INFORMING THE APPLICANT OF THE 
COMMUNICATION OF THE INTERNATIONAL 
APPLICATION TO THE DESIGNATED OFFICES 
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